X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:content-type
	:content-transfer-encoding:message-id:date:from:to:subject
	:in-reply-to:references; q=dns; s=default; b=jy7G1/5NimqLTfVi9mp
	/zP8vDkPfzz/kwQCiZRQxj9ZM9i0sazTMtiUPrTykB59+glpwKGdcwBj51YRqD5X
	AzRjE9n/CfWJ8J0gNUp6itOp49stpHG7kk+LQ4FuWyRIfqYNHZvpgBw86M8x6+7x
	YbyYGxCFdCUO5LXRoJmCz3ZA=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:content-type
	:content-transfer-encoding:message-id:date:from:to:subject
	:in-reply-to:references; s=default; bh=MQwSMRkJvffsX1RP4nHlsz+Qk
	I4=; b=IeBpurRav9JqnZjsROnjzXoRBVou3XvDmBxdtsMy6stuQAVT8rRCu3sqa
	QN6irdI8sivZchG8m6S5+lVjxv8APY+0JxHNbVp3nFuy2jMtPebOGkd4FgcPiywM
	qGqp9epr+SyT99NPAX0Q39UeRP0Xs3AniUbdiZSnbvdBl25HT8=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=0.3 required=5.0 tests=AWL,BAYES_20,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2
X-HELO:	mailbackend.panix.com
MIME-Version:	1.0
Message-ID:	<22071.12068.858109.210047@compute03.cs.columbia.edu>
Date:	Mon, 2 Nov 2015 04:38:44 -0500
From:	Jonathan Lennox <lennox AT cs DOT columbia DOT edu>
To:	cygwin AT cygwin DOT com
Subject:	Re: fstat st_size on open files on Parallels filesystem is wrong
In-Reply-To:	<20151021110734.GO5319@calimero.vinschen.de>
References:	<21333 DOT 25325 DOT 11106 DOT 958642 AT compute01 DOT cs DOT columbia DOT edu> <227151856 DOT 20140421223417 AT yandex DOT ru> <21333 DOT 26515 DOT 393838 DOT 380071 AT compute01 DOT cs DOT columbia DOT edu> <20140422081628 DOT GC2339 AT calimero DOT vinschen DOT de> <21334 DOT 55207 DOT 784319 DOT 488271 AT compute01 DOT cs DOT columbia DOT edu> <20140423084056 DOT GJ2339 AT calimero DOT vinschen DOT de> <21335 DOT 61113 DOT 963950 DOT 516021 AT compute01 DOT cs DOT columbia DOT edu> <20140423172413 DOT GQ2339 AT calimero DOT vinschen DOT de> <22038 DOT 38637 DOT 802707 DOT 846218 AT compute03 DOT cs DOT columbia DOT edu> <20151021110734 DOT GO5319 AT calimero DOT vinschen DOT de>

On Wednesday, October 21 2015, "Corinna Vinschen" wrote to "cygwin AT cygwin DOT com" saying:

> On Oct  8 12:16, Jonathan Lennox wrote:
> > Hi, following up on this issue from last year.  The message I'm replying to
> > is at <https://cygwin.com/ml/cygwin/2014-04/msg00524.html>.
> > 
> > The problem is weird behavior in Parallels Desktop-hosted Windows VMs, when
> > accessing the host's native Mac OS X filesystem.  See the thread for the
> > details.
> > 
> > On Wednesday, April 23 2014, "Corinna Vinschen" wrote to "cygwin AT cygwin DOT com" saying:
> > 
> > > > At this point this is looking pretty clearly like a Parallels Tools bug.
> > > > I'll report it to them.
> > > 
> > > Yes, that sounds good.  Given that, I'm wondering if we should try to
> > > workaround this problem at all or rather wait to see if the vendor will
> > > fix the issue.
> > 
> > No such luck, despite two major version revisions of Parallels Desktop (I'm
> > now on version 11.0.2) and moving to Windows 10 as the guest OS -- the bug
> > perists, unchanged.  So it looks like Cygwin will need to add a workaround
> > for this filesystem to fix the problem.
> 
> 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?

I re-ran the test, no change. Changing the order gives the same result --
FileStandardInformation works, FileNetworkOpenInformation doesn't.

> Just create a hardlink on that drive using native means:
> 
>   $ touch foo
>   $ cmd /c mklink /h bar foo
> 
> Error at this point?  No hardlinks.  Otherwise:

"You do not have sufficient privilege to perform this operation."  Is that
sufficient proof?

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.  So I
can't test hard links as administrator.

>   $ ls -li foo bar
> 
> 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.

However, when I create a hardlink on the underlying (Mac) file system, the
inode numbers that Cygwin shows are not identical.  So "no hardlinks" seems
very likely.

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -