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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=fm/i0a8FSEJit6m1UTBXMCWSv6alWppvZ4D6FeDyCymTODB7r/dzg
	+edQ+FLj9DWw3FwGlDe6crwxuQ7gRDfgp1c323zkrzrhpY93i2yaTZ7q3thaSotK
	WWQ9ypAELV0qhCKixNBRSOZZVmjQro0YrGjE3AXgPZcoFAhUmhy1+0=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=o2GM2nzi5BMFgg38BpMnCE7uXh4=; b=Fi34AbXniTq1YW02Xa1S1iiOyx5d
	tn1QpNJxStNEzS+Ouyo+kldFeeuCU7bMxPKip6pCx0RpYdx7RIggfHpXLU2jmfYx
	SbU8fpK+9Rl2ycAGHdRKFGnTstwv2A4B87ejOXrgPA2woexxwSl3ctBkFU6iPEqA
	H5kdnpWSXPQ8VAY=
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=-4.9 required=5.0 tests=AWL,BAYES_00,UNSUBSCRIBE_BODY autolearn=no version=3.3.2
X-HELO:	calimero.vinschen.de
Date:	Tue, 22 Apr 2014 10:16:28 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: fstat st_size on open files on Parallels filesystem is wrong
Message-ID:	<20140422081628.GC2339@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
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>
MIME-Version:	1.0
In-Reply-To:	<21333.26515.393838.380071@compute01.cs.columbia.edu>
User-Agent:	Mutt/1.5.21 (2010-09-15)

--Md/poaVZ8hnGTzuv
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Apr 21 14:46, lennox AT cs DOT columbia DOT edu wrote:
> On Monday, April 21 2014, "Andrey Repin" wrote to "lennox at
> cs.columbia.edu, cygwin at cygwin.com" saying:
>=20
> > Greetings, lennox at cs.columbia.edu!
> >=20
> > > I=E2=80=99m running cygwin64 1.7.29 in a Windows 8.1 Pro virtual mach=
ine, running in
> > > Parallels Desktop 9.0.24229 on Mac OS X 10.9.2.
> >=20
> > > Parallels Desktop automatically mounts my Mac OS X home directory as =
a Z:
> > > drive in Windows.  Cygwin mount reports this drive as being type "prl=
sf".
> >=20
> > > Unfortunately, I've discovered that if I have an open file on this
> > > filesystem which has been written to, the size returned by Cygwin fst=
at() on
> > > the open file is wrong.  A stat() of the file after it's been closed =
is
> > > correct.
> >=20
> > > This has the consequence that emacs always thinks saved files have be=
en
> > > modified externally, since emacs looks at files' sizes (as well as th=
eir
> > > modification times) to detect external changes.  This makes emacs
> > > near-unusable.
> >=20
> > > This problem does not occur for files in my Cygwin home directory, or=
 other
> > > locations mounted on my Windows C: drive.
> >=20
> > > I've attached a simple unit test program that illustrates the problem.
> > > I've also attached my cygcheck -s -v -r output.
> >=20
> > > 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.
> >=20
> > You never flushing the buffer in your test code, or I'm reading it wron=
g?
>=20
> This is using Posix APIs -- open() / write() -- not C APIs, fopen() /
> fwrite(), so there shouldn't be a buffer?  Notice that the test behaves a=
s I
> expect for a file on NTFS.
>=20
> Adding a call to fsync() prior to the fstat() call doesn't change anythin=
g.

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

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

--Md/poaVZ8hnGTzuv
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJTViVcAAoJEPU2Bp2uRE+gTSwP/1mPxk86586sUW9y4lTjkyGy
9TPNJL5cvL5dXNriFxhHAV9aERuyUjCTqH1LZ9k56CWm3qxy6Fk4ByDW7/bbA1vf
s//rxW/9wYkj49+lNDNRUL0fx0dsyLRsw4glHq1X6TpjxILtn40O6DtSGPhaDU9l
PmYkdFaruaI4n7iaGC054+UnLIvELlEH0dIhQBihpk4pSRxzHEg7wzg0vxhoZORQ
LB0snI17FlcE9ixPlpksVMIm3wEhFsUFNSbqxeIfosSO+6u9tgHl5UeXraKLMQV3
Ko78fLBYt8NI9/yHpfr0f25gme0jFJVEFWq/InIKxCmQ2cSbpdxBqmbrmYkJ4P90
pNRPwCVxJuGO9gFzL/raH9bLF1OCl2XkUa3kAKM1kRL8T7dFltUuv150K4cQWhWk
a93uN5BefdrHKXkfJrgTJM62aZRHZTwCnf3xfKZxDxzibwcs+4rjisbdHDf9bVt0
alKt+gmwASxqsMOlk1iUm0Xrmgj1XrzKTJJ2qghMcw2GKmC6guh4ichVSLCCSso/
pCzHyDR3wpeiSvNXl74wCbMRIncDVTJiRpvCiVkfWW+ouGGPLpF8aXkHG/z5O9fM
676XYFuYQwDFyMCO9/cid5H8AN5sCzSIunfFr5+GCvAjMYHIcbGaAvLQV5FSH+9/
9Zd9IpcjR1mPaCCnIelZ
=h8jA
-----END PGP SIGNATURE-----

--Md/poaVZ8hnGTzuv--

- Raw text -