X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:mime-version:content-type
	:content-transfer-encoding:to:subject:in-reply-to:references
	:from; q=dns; s=default; b=us5M6ih13aGuJovAP+NfT32BEe3bLEXl4a1ry
	47muNgDxqtiKfe+bK+JX6ZH7RnNpqIus/GXlmEbgwI3OC3IbSZD5ks9bZDmeopkr
	v8kBYKb0MDvCvP7h9LCWbJCgEQtF5hcisEML4rnv8J+ZmzgWvCwYgPs+rR0rhhMk
	HupOgw=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:mime-version:content-type
	:content-transfer-encoding:to:subject:in-reply-to:references
	:from; s=default; bh=9zV1RiTN9efZWzcoiAm9gmm3/vo=; b=E0xpvqk3muF
	IHfOt743NPb5XrGA2n1d7QW9QKaTHFSQWISEsCXhcQzj06vAeF50R6CCts1yRvUr
	pTFI+XLXV8OY6zNBYADO8v1EtxwlDaKds104sdcIFPCpWT4XQUcaEA2gM0muImgY
	jxsPv+FGbedR6trZW/3OF+3MIOI0xSmY=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-0.4 required=5.0 tests=AWL,BAYES_00,UNSUBSCRIBE_BODY autolearn=no version=3.3.2
X-HELO:	mailbackend.panix.com
Message-ID:	<21334.37961.774546.475597@compute01.cs.columbia.edu>
Date:	Tue, 22 Apr 2014 12:09:45 -0400
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: fstat st_size on open files on Parallels filesystem is wrong
In-Reply-To:	<20140422081628.GC2339@calimero.vinschen.de>
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>
From:	lennox AT cs DOT columbia DOT edu
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id s3MGAH9T032516

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

- Raw text -