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
The other 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.
Separate codepath is probably because most files are not sparse on most
filesystems, and copying the range is faster, especially if it can mmap input
and output, and let the pager/swapper do the work.
--
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
--
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
