DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 50FGDgcX3937339 Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 50FGDgcX3937339 Authentication-Results: delorie.com; dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=niLN1/UW X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 517083858C3A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1736957621; bh=GUpvKlyS3CsvtPuhPV+p0h4XN8Bb/ayS7zo1T+s9r8A=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=niLN1/UWWMM4eNev6VsO16TEEMuRAn09ys4Eg0voyxK5lIUjL9rfWG0aJCsI576Ml 6a2HWdtKNZsDzIzCUGwAugMGrAwhye9q1pl+jAsx4BiN3a0RzHBeAiioyRRxozjeE1 YDYvvLP8CId+rs+YAgBZVEbS+0nytGRnVXm8lbRk= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3F4743858C3A ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3F4743858C3A ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1736957584; cv=none; b=NKVddjFYyckZ2ssGj0neGrmBJ4aH2hnfMiCidjPlKLKTsxycaWjJo5mVtzDLbC73kjZrGwuAw7qORKqdOcMRyUaMEnEdrv76P1egAihTUu9DiWgCVEiCkcZIDSatYqi3G3RDpkWdQMxRBRgFiBv2wMaQhReoOwDyauFlssjjnQg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1736957584; c=relaxed/simple; bh=WmGVNoVlPBcsVnLi33iIL0M7MO7AJblbJA4kYioVSq0=; h=Message-ID:Date:MIME-Version:From:Subject:To:DKIM-Signature; b=rVw8F4XGB8FzFYTRmOmeuuFqcglBra9AC/+TL7KPq0WsOvgRkuEGlv98fCR7vzQlBviYJt5+TYjaCPWQDdw3ZwGxqWDtMmYspLlucIjkcrIlRGBdA2mU8yqSP756Q/Fmo0pv0JJFYzeQ85d7kTK4Hxn5D9E378kTv7IISewt6Gg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3F4743858C3A Message-ID: Date: Wed, 15 Jan 2025 09:12:33 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Cygwin 3.6 possible issue handling compressed .pdb files on SSD? To: cygwin AT cygwin DOT com References: <4712dcf7-1d4d-4d27-b7c1-b705d3a0a553 AT SystematicSW DOT ab DOT ca> Content-Language: en-CA Organization: Systematic Software In-Reply-To: X-Rspamd-Queue-Id: 1E62E80019 X-Rspamd-Server: rspamout03 X-Stat-Signature: 1ya5c83e9znc1g8yo14csaxbnyi6jwn8 X-Session-Marker: 427269616E2E496E676C69734053797374656D6174696353572E61622E6361 X-Session-ID: U2FsdGVkX18kDKJNhr4pT7TfqF2UQ3hauZmItr7oOJQ= X-HE-Tag: 1736957554-303931 X-HE-Meta: U2FsdGVkX1/XZSWKYzeG3+3bMwEOuX2em4enEU9upHq0RKbqcO0Anu5HZr5kgK+E44yGGqs77jQzpeIslCsFUOzvEexH/npndkFhyfxfDMdPwL6WW7v49e7waJcVTPfYVm7FrXWywLogrMbNDXLzPkKyLg3cDtvWMIlUCRfysPy1V/IoOYya3BsHuIDyGZgw/1CSsleMP6KzoAiY4fqi5PZIYwcHYGB+9tGbadUco0EKhs9OqPbS6tDy9hJ3xqFtsM2UwOX9amXFi+3zYo50/tLH/laJ2aIJLN4Bk0FGKvk2zR/YDMpB1HGDzDIrrqK5GPm0u3twYQLwp/nuv+Lxq3+9x0VMxWz01WAwQxKipRYrg31F1TVXeWjTI3VyWBCyVOPfaAh+vpmD0ndlxRF4lF3q6gTrwkV2bYCGCaJG+vztuQIMOyiA1XeOjytu5hoeyGFxQe3ICeg/xfpx0Xr3+g== X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Brian Inglis via Cygwin Reply-To: cygwin AT cygwin DOT com Cc: Brian Inglis Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 50FGDgcX3937339 On 2025-01-14 03:13, Roland Mainz via Cygwin wrote: > On Tue, Jan 14, 2025 at 7:19 AM Brian Inglis via Cygwin > 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 >>> >>> 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 -- 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