This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: fstat st_size on open files on Parallels filesystem is wrong


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?

> 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?

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:

  $ 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.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpQ0J89O5AJM.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]