On Tuesday, April 22 2014, "Corinna Vinschen" wrote to "cygwin at cygwin.com" saying:
> On Apr 21 14:46, lennox at 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? It's certainly possible that the file system driver in the Parallels Tools has a bug, and if so I'm happy to report it to Parallels. I'll see if I can reproduce the test case using just Win32 APIs. Are there any particular gotchas I should watch out for, or should just looking at what Win32 functions are called in fhandler_disk_file.cc be sufficient? -- Jonathan Lennox lennox at cs.columbia.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