From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36788 invoked by alias); 2 Nov 2015 11:23:38 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 36776 invoked by uid 89); 2 Nov 2015 11:23:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 02 Nov 2015 11:23:37 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id CFB52A80610; Mon, 2 Nov 2015 12:23:34 +0100 (CET) Date: Mon, 02 Nov 2015 11:23:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: fstat st_size on open files on Parallels filesystem is wrong Message-ID: <20151102112334.GC5319@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <227151856.20140421223417@yandex.ru> <21333.26515.393838.380071@compute01.cs.columbia.edu> <20140422081628.GC2339@calimero.vinschen.de> <21334.55207.784319.488271@compute01.cs.columbia.edu> <20140423084056.GJ2339@calimero.vinschen.de> <21335.61113.963950.516021@compute01.cs.columbia.edu> <20140423172413.GQ2339@calimero.vinschen.de> <22038.38637.802707.846218@compute03.cs.columbia.edu> <20151021110734.GO5319@calimero.vinschen.de> <22071.12068.858109.210047@compute03.cs.columbia.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tBHT5Mz29exfSJaj" Content-Disposition: inline In-Reply-To: <22071.12068.858109.210047@compute03.cs.columbia.edu> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-11/txt/msg00026.txt.bz2 --tBHT5Mz29exfSJaj Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3126 On Nov 2 04:38, Jonathan Lennox wrote: > On Wednesday, October 21 2015, "Corinna Vinschen" wrote to "cygwin@cygwin= .com" saying: > > On Oct 8 12:16, Jonathan Lennox wrote: > > > No such luck, despite two major version revisions of Parallels Deskto= p (I'm > > > now on version 11.0.2) and moving to Windows 10 as the guest OS -- th= e bug > > > perists, unchanged. So it looks like Cygwin will need to add a worka= round > > > for this filesystem to fix the problem. > >=20 > > Ok, we could do that. Can you compile and run the testcase from > > https://cygwin.com/ml/cygwin/2014-04/msg00523.html again? Does it > > still show 0 vs. 12 bytes? Dumb extra test: Does the output change > > if you reorder the calls, requesting FileStandardInformation first, > > FileNetworkOpenInformation second? >=20 > I re-ran the test, no change. Changing the order gives the same result -- > FileStandardInformation works, FileNetworkOpenInformation doesn't. Ok, so it's not about some caching. > > Just create a hardlink on that drive using native means: > >=20 > > $ touch foo > > $ cmd /c mklink /h bar foo > >=20 > > Error at this point? No hardlinks. Otherwise: >=20 > "You do not have sufficient privilege to perform this operation." Is that > sufficient proof? No. > Unfortunately, when I do "Run As Administrator" on MinTTY, the Mac drives > (/cygdrive/z and /cygdrive/y) don't show up. I don't know why that is. S= o I > can't test hard links as administrator. That's a security feature of UAC. You can change that in the registry. As administrator: regtool -d set /HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVers= ion/Policies/System/EnableLinkedConnections 1 Then reboot. > > $ ls -li foo bar > >=20 > > Are the inode numbers identical? Congrats, hardlinks work. But given > > the general FAT-iness of the getVolInfo output, I guess it doesn't > > maintain hardlinks. >=20 > However, when I create a hardlink on the underlying (Mac) file system, the > inode numbers that Cygwin shows are not identical. So "no hardlinks" see= ms > very likely. Given the filesystem flags, Cygwin treats your FS as some kind of FAT anyway, so this isn't convincing. I doubt they work anyway, but if you really want to test it, use your orignal testcase and replace the NtQueryInformationFile like this: FILE_INTERNAL_INFORMATION fii; status =3D NtQueryInformationFile (h, &io, &fii, sizeof fii, FileInternalInformation); if (!NT_SUCCESS (status)) fprintf (stderr, "NtQueryInformationFile: 0x%08x\n", status); else printf ("inode number %llu\n", fii.FileId.QuadPart); Then call this application multiple times on some well known hardlinks to the same file. If they have the same number, all the time, hardlinks work. I added support for this filesystem (called prlfs in mount output) and without hardlink support for now. I uploaded a new developer snapshot to https://cygwin.com/snapshots/ Please give it a try. Thanks, Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --tBHT5Mz29exfSJaj Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWN0e2AAoJEPU2Bp2uRE+gOuMP/RgKDxf7OwvY6Hb1BHWebKsi m8AXl5pszTRxPtS6pFg5OLY98i8Sqh0GlX8LEMd+H8zqNxKEQu4Q5A3w5ntugHTs Y+0cx0Jq7zVuKw8vL/7g1/M6FkRqVdNc1XpYMX3FTrmkk2OHjj8IindRKYypQqLk zGXV0aP9VDxfM63cYnuynVuTSTZ49E6AP/nzHPN+tH+s/mCGA/Plh6MruPbjLtkV CmhHK1We3mqlWvzEhN4iJRr/a1J+cmTv6vLHIB88NbMFzOi1i5M7M7igw+U/0dZk KgmfFmMqm9fqmbJCI4yYrF7YzoghuanLusxnl/qDUYB727K6CxBrjrRX68eKULBV SG3I8X37zVMeHPpkCKRp229Ro8E4uuv3MTFb4efhW+iU/J97j0FSucdCtldFg+w3 IvwMfbgN72OBux8gJSxlGE63kRGsptdWZ94tZOcFQQ0I/DEjHzFEOI/4q4l7w+iQ a4CY6bz8bCIqsfH6ZbDoVL9sDhOBLssa8joxC6p9q/KkJRBRlgfitWcdUN9xBiSj IXCYLosyjkOi9Fy4bZ+u9okOVZUnDI7/ZA1B0lyPkCCZzJXNJrSv0LJ0wVRFcGA1 7MmRFyr0HAz7AtdP4WpeI7pJ5v782zTCzvi9oezGzC4lQGqlulw+QfaibBplFpu1 eZGsXUwRVkmt7UlCsv0Y =GlI4 -----END PGP SIGNATURE----- --tBHT5Mz29exfSJaj--