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

[Roland Mainz]

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

----

Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)