fstat st_size on open files on Parallels filesystem is wrong

[Corinna Vinschen]

On Apr 21 14:46, lennox@cs.columbia.edu wrote:
> On Monday, April 21 2014, "Andrey Repin" wrote to "lennox at
> cs.columbia.edu, cygwin at cygwin.com" saying:
> 
> > Greetings, lennox at cs.columbia.edu!
> > 
> > > 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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20140422/288801e9/attachment.sig>