Message-ID: <4D2783A3.5000008@redhat.com>
Date: Fri, 07 Jan 2011 14:20:35 -0700
From: Eric Blake <eblake AT redhat DOT com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Strange fstatat / stat behavour on directories causing tar "file changed as we read it" error
References: <3501944D149644D394474781054F5E98 AT multiplay DOT co DOT uk>
In-Reply-To: <3501944D149644D394474781054F5E98@multiplay.co.uk>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig5CF67219E832FC4C37D53547"
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

--------------enig5CF67219E832FC4C37D53547
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 01/07/2011 11:21 AM, Steven Hartland wrote:
> It turns out that the value of st_size returned by a call
> to fstatat on a directory can change even though there
> have been no changes at all to said directory or its
> children.

What file system is this on?  Someone else reported the same behavior
for "Samba share on QNX through Virtual PC." - if the problem is limited
to just a subset of (known-buggy) file systems, it would be nicer to
limit the workaround to just those file systems (and have st_size always
return 0 for directories from those systems).

> The attached patch fixes this strange behaviour by ignoring
> size changes for directories as well as correcting the file
> size check to also detect file shrinks as well as growths,
> which seemed very odd.

Thanks for the patch - we'll see if I can get enough free time to apply
it and ship a patched tar, or whether cygwin 1.7.8 with a better
workaround for the issue gets released first (since there was already
talk of getting 1.7.8 complete sometime this month).

>=20
> Is there some "meta data" caching going on in cygwin or
> Windows which causes this very strange behaviour?

Giving us more details about your filesystem would help us answer that
question.

--=20
Eric Blake   eblake AT redhat DOT com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


--------------enig5CF67219E832FC4C37D53547
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJNJ4OjAAoJEKeha0olJ0NqLr0H/RckzqrpqsD98sU8IpJUdsJP
kU2/vRNMkBwrXBG/Y/Q/y6ZA4v9KmVcUwuo0hMVRtvnT2txHGG27OjSobj2aUjw+
mjTZSIKWqH1I46HZ6Bki1YzEyMDc0Qk8sZkpdEgUI5cdobVbQIp8rnMcYj9yX63i
D6vXmJsIWMmTkeUr4gltUmAZte10aRyAUr34VV3/fTiO9qSDarM3NKodZE1xYz62
2Gx0hJUDrjrR0I+XlRmwuaM8fU5EH8faGG7gRDKh2u81c6rN8BE3Q2tBllYfFz6d
Eby+jApZQx1T/MDqxZSbo8dBU1VnxmNgDvK6wKftjgf7idHUzwXVJ3eocAbZlrQ=
=gE95
-----END PGP SIGNATURE-----

--------------enig5CF67219E832FC4C37D53547--