This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: fstat st_size on open files on Parallels filesystem is wrong
- From: Jonathan Lennox <lennox at cs dot columbia dot edu>
- To: cygwin at cygwin dot com
- Date: Mon, 2 Nov 2015 04:38:44 -0500
- Subject: Re: fstat st_size on open files on Parallels filesystem is wrong
- Authentication-results: sourceware.org; auth=none
- 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@cygwin.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@cygwin.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