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 Apr 21 14:46, wrote:
> On Monday, April 21 2014, "Andrey Repin" wrote to "lennox at
>, cygwin at" saying:
> > Greetings, lennox at!
> > 
> > > Iâm running cygwin64 1.7.29 in a Windows 8.1 Pro virtual machine, running in
> > > Parallels Desktop 9.0.24229 on Mac OS X 10.9.2.
> > 
> > > Parallels Desktop automatically mounts my Mac OS X home directory as a Z:
> > > drive in Windows.  Cygwin mount reports this drive as being type "prlsf".
> > 
> > > Unfortunately, I've discovered that if I have an open file on this
> > > filesystem which has been written to, the size returned by Cygwin fstat() on
> > > the open file is wrong.  A stat() of the file after it's been closed is
> > > correct.
> > 
> > > This has the consequence that emacs always thinks saved files have been
> > > modified externally, since emacs looks at files' sizes (as well as their
> > > modification times) to detect external changes.  This makes emacs
> > > near-unusable.
> > 
> > > This problem does not occur for files in my Cygwin home directory, or other
> > > locations mounted on my Windows C: drive.
> > 
> > > I've attached a simple unit test program that illustrates the problem.
> > > I've also attached my cygcheck -s -v -r output.
> > 
> > > Any ideas?  Is this a Cygwin bug, a Parallels bug, or something else?
> > > Glancing over the Cygwin code, I see that there are a few cases where fstat
> > > has special cases for certain filesystem types.
> > 
> > You never flushing the buffer in your test code, or I'm reading it wrong?
> This is using Posix APIs -- open() / write() -- not C APIs, fopen() /
> fwrite(), so there shouldn't be a buffer?  Notice that the test behaves as I
> expect for a file on NTFS.
> Adding a call to fsync() prior to the fstat() call doesn't change anything.

This is actually a bad sign.  The problem you're describing occurs on
NFS, too.  If you write to the file, a subsequent call to fetch stat
attributes does not return the actual size of the file, but the size at
the time the handle has been opened.

However, on NFS, a call to FlushFileBuffers helps to kick stat back into
shape.  That's the Win32 function called from fsync as well.  What is
Cygwin supposed to do if that doesn't work?


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

Attachment: pgpJeV2iNF_F4.pgp
Description: PGP signature

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