Mail Archives: cygwin/2011/01/12/10:01:34
--------------enig02164FA21554370C1D61207A
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 01/12/2011 03:47 AM, Corinna Vinschen wrote:
>=20
> On second thought, let's take a step back.
>=20
> Actually, directories can change all the time. Why on earth is tar
> checking the st_size member of a directory at all? That's a bug IMO.
> No application should do that. I understand that a change in the inode
> number points to the fact that the directory has been replaced
> underfoot, but why should tar be concerned that a directory has changed
> its size while it's reading files from it? I mean, even during a tar
> backup, there's no reason to expect that files are *not* added or
> deleted to a directory by other applications, and these actions may
> naturally change the size of the directory.
When tar is trying to capture the entire contents of the directory, any
modification to that directory (including adding a file to the directory
which changes the st_size of the directory) means that tar missed
something, so tar emits a warning to tell you about that fact.
>=20
> Having said that, I don't think it's correct to change Cygwin here.
> It's just a bug in tar.
I'm not sure we've established that point yet, but I'll raise the
question upstream. But, assuming tar is doing the right thing...
> The fact that the directory size changes even
> if the content hasn't changed is just a side effect of the OS MO. It
> doesn't matter if the directory has actually changed or not. It's not
> in the hand of a single application.
then cygwin's behavior DOES matter to tar - no other system changes the
st_size of a directory without ALSO adding or deleting files within that
directory and also updating the st_mtim of the directory; at which point
tar is entirely within its rights to complain (the directory changed
while trying to read it, so the tar file may be incomplete). Locking
st_size at 0 avoids the issue entirely, whether or not upstream tar
agrees that checking changes in st_mtim but ignoring changes in st_size
would be a more appropriate behavior.
--=20
Eric Blake eblake AT redhat DOT com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--------------enig02164FA21554370C1D61207A
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/
iQEcBAEBCAAGBQJNLcI+AAoJEKeha0olJ0Nq8HwH/09QXf6xvV5avB4OcfG1R61U
eDV5XFNiohVoGBcU4o7OIFhfJRHpPQXepdjgJYpO3PPVpJeg+QNfnHAT5pb2MfwO
xtq6SgEe2VlHZizYmff0GDVH9lK4WQIGT1gtOJTHnkI7CAooXSNMaqfFoLIABpSQ
3Ae03BHhgdSEnPphsn1m2qs0rphUHTV166myIS0AXvORtZaZl0Nb+kMJwrZQb7Nz
tENIjJHH6ztlhIwIy3XumbAj8GM3dQ7yuYHJKgnwxYLfByHcO1ncrffj3duh8dAa
y1mvg/DUSYUuiJ38diC3WSqOd0VPMrRellx+J3HrZdPubaHzQRv4LUP/5CNLa0E=
=aqZ/
-----END PGP SIGNATURE-----
--------------enig02164FA21554370C1D61207A--
- Raw text -