Cygwin 3.6 /usr/bin/cp from "coreutils" version 9.5-1 stuck in an endless loop...

[Christian Franke]

On Tue, Jan 14, 2025, 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?
> ...
> 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)"
> (
>         ...
>         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

The infinite loop occurs because SEEK_DATA behaves different from Linux 
and POSIX, see:
https://sourceware.org/pipermail/cygwin/2025-February/257330.html

-- 
Regards,
Christian