This is the mail archive of the
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: Thu, 8 Oct 2015 12:16:45 -0400
- 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>
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
On Wednesday, April 23 2014, "Corinna Vinschen" wrote to "email@example.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.
The output of /usr/lib/csih/getVolInfo seems to be unchanged from the output
I reported last year.
> Thanks. This looks pretty much like a filesystem pretending to be
> FAT-like. There may be another problem lurking, which is, are the inode
> numbers (called "FileId" or "IndexNumber" in Windows) persistant? With
> FAT this is not the case, and given the above, it might be a problem...
> ...or not. I just realize that Cygwin doesn't even try to use the
> FileId as inode number on filesystems with FILE_PERSISTENT_ACLS==FALSE
> so, never mind.
> OTOH, does it support hardlinks? If so, two hardlinks to the
> same file would have different inode numbers on Cygwin.
How would I figure these points out?
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple