Cygwin 3.6 possible issue handling compressed .pdb files on SSD?

[Brian Inglis]

On 2025-01-14 03:13, Roland Mainz via Cygwin wrote:
> On Tue, Jan 14, 2025 at 7:19 AM Brian Inglis via Cygwin
> <cygwin@cygwin.com> wrote:
>> On 2025-01-13 13:10, Roland Mainz via Cygwin wrote:
>>> I just hit an endless loop with /usr/bin/cp from "coreutils" version
>>> 9.5-1 copying a larger *.pdb file (it seems that only this specific
>>> file is affected...) from Visual Studio 19.
>>>
>>> Using strace -p $pid_of_cp I get this output:
>>> ---- snip ----
>>> ...
>>>     212 11917852 [main] cp 1319 fhandler_base::lseek: setting file
>>> pointer to 1708032
>>>     200 11918052 [main] cp 1319 lseek: 1708032 = lseek(4, 1708032, 3)
>>>     239 11918291 [main] cp 1319 fhandler_base::lseek: setting file
>>> pointer to 1708032
>>>     266 11918557 [main] cp 1319 lseek: 1708032 = lseek(4, 1708032, 4)
>>>     160 11918717 [main] cp 1319 fhandler_base::lseek: setting file
>>> pointer to 1708032
> [snip]
>>> ...
>>>    ---- snip ----
>>> This never stops, even after a couple of hours, but cp(1) can be
>>> killed with <CTRL-C>
>>>
>>> Downgrading to "coreutils" version 9.0-1 fixes the problem.
>>>
>>> Cygwin version itself is
>>> "CYGWIN_NT-10.0-19045 chickenmonster 3.6.0-0.304.g264544bf72f6.x86_64 2025-01-13 10:15 UTC x86_64 Cygwin"
>>
>> The command is not simply looping, it is repeating 4 SEEK_HOLE, 0 SEEK_SET, 3
>> SEEK_DATA, at the same file offset, which looks like some kind of retry cycle,
>> but each of the operations are succeeding.
>>
>> What is the exact command you are running and what are the source and target
>> filesystems?
> 
> See https://nrubsig.kpaste.net/70f1c8
> 
>> What is the exact size of the file and what device type is it on: SSD or HDD?
> 
> "Virtual SSD", which is VMware's NVME emulation
> 
>> What is the allocation size of the file and how many 4KB holes (zeroed blocks)
>> are in the file?
>>
>> Could you please try running the command under strace to see what it is doing
>> before it gets in to that cycle?
> 
> See https://nrubsig.kpaste.net/70f1c8 for the strace log.
> 
> I think I found the problem:
> The *.pdb file uses NTFS compression:
> ---- snip ----
> /bin/winfsinfo filebasicinfo "$(cygpath -w
> $PWD/../build.vc19/x64/Debug/nfs41_driver.pdb)"
> (
>         filename='C:\cygwin64\home\roland_mainz\work\msnfs41_uidmapping\ms-nfs41-client-kofemannvacation\build.vc19\x64\Debug\nfs41_driver.pdb'
>         CreationTime=133812707624654816
>         LastAccessTime=133813220892976366
>         LastWriteTime=133812707639811081
>         ChangeTime=133812707639811081
>         typeset -a FileAttributes=(
>                 FILE_ATTRIBUTE_ARCHIVE
>                 FILE_ATTRIBUTE_COMPRESSED
>         )
> )
> ---- snip ----
> 
> If I remove the "FILE_ATTRIBUTE_COMPRESSED" flag /bin/cp works without problems.
> I think the issues here are:
> 1. Coreutils 9.5-1 /bin/cp erroneously assumes that a file is sparse
> if the number of blocks is smaller than $((filesize / fs_blocksize)) -
> but in this case the file is NOT sparse, just compressed.
> 2. The loop to copy a sparse file is faulty because there are no holes
> in that file. That itself is IMHO already a bad idea to have a
> separate codepath for sparse files, just the normal codepath should
> use SEEK_HOLE and just skip those in the destination

A possible issue is that Cygwin assumes sparse files on SSD, so we need 
fhandler/disk_file:fstat_helper to allow cp to handle compressed files normally.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher  but when there is no more to cut
                                 -- Antoine de Saint-Exupéry