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.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
