Re: refuse to update certain files upon extraction

--===============0550294139==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="00sTfE/IIAT5d2r5"
Content-Disposition: inline


--00sTfE/IIAT5d2r5
Content-Type: multipart/mixed; boundary="lHuqAdgBYNjQz/wy"
Content-Disposition: inline


--lHuqAdgBYNjQz/wy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Message by -Joerg Schilling- from Tue 2008-03-18:
> Lasse Kliemann <[email protected]> wrote:
>=20
> > * Message by -Joerg Schilling- from Tue 2008-03-18:
> >
> > > The problem is a Linux kernel bug.
> > >=20
> > > Any other backup tool (like e.g. dump/restore) will run into the same=
 problem
> > > as Linux did not update the timestamp from the directory=20
> > > "send-backup-test/log/supervise/".
> > >=20
> > > You need to send a bug-report against Linux and get a fix for this pr=
oblem....
> >
> > I've already prepared a minimal example to prove this, see the attached=
=20
> > files. The ctime of `sub' changes the first time that `rename' is run, =
but=20
> > not the second. I also tried this on Solaris, and there the ctime is=20
> > updated after the second run of `rename'.
>=20
> Do you know whether your original problem was caused by a rename or rathe=
r a=20
> unlink/create chain?
=20
It was caused by a rename, as in the attached rename.c (that's the one from=
=20
my old message <[email protected]> and not th=
e=20
one I sent minutes ago).

This rename.c is more complicated, but it was the simplest thing I managed =
to=20
construct to reproduce the problem in conjunction with incremental dumps.=
=20

By the way, I just did some research on the rename-ctime-thing on Linux, an=
d=20
it appears that something similar was noticed back in 2004 already. There a=
re=20
close to no responses to the patches sent in at that time. Someone even wro=
te=20
that this behavior is okay according to the SuS, but I am not completely su=
re=20
that he refers to the same thing. The current Linux Bug Tracker does not gi=
ve=20
any hits for 'ctime rename', so I will file a bug report there now. Let's s=
ee=20
what happens.

Lasse

--lHuqAdgBYNjQz/wy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="rename.c"
Content-Transfer-Encoding: quoted-printable

#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/stat.h>

int main(int argc, char** argv) {
	int fd;

	fd =3D open("x", O_WRONLY | O_NDELAY | O_TRUNC | O_CREAT, 0644);=09
	write(fd, "x", 1);
	close(fd);

	fd =3D open("new", O_WRONLY | O_NDELAY | O_TRUNC | O_CREAT, 0644);
	write(fd, argv[1], 3);
	close(fd);
	rename("new", "a");

	mkdir("sub", S_IRWXU);
	fd =3D open("new", O_WRONLY | O_NDELAY | O_TRUNC | O_CREAT, 0644);=09
	write(fd, argv[2], 3);
	close(fd);
	rename("new", "sub/b");

	return 0;
}

--lHuqAdgBYNjQz/wy--

--00sTfE/IIAT5d2r5
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)

iQIcBAEBAgAGBQJH3+RsAAoJEFYll6N4nhdv0y0QAJJIaREv2wNsFEZOSsz+duvr
baDC5tmZQ1UcNaDdYqJl3q8JGrBiCk2SXAcdvJJGXZGloGdH/IxeSnkuVmOVTQs8
QSk4FpK5jeyvnpzcu4cQEC4d1Yn6McP02FIG7ZY+jnAhOuCE0CNbgRsiR0PQjCxw
1/GO8AfTYFTTUE2uTU++iSLIdjEw0UR3JX98otFYwUeRZc8ZvIe1+KKeHh1Y2+mX
cNp2OwaeTQgT0cAFlREUfzMpyKscPa4H3vA2f8JbacFFqsn2U0BKvBXkJm5TwSom
t4TVcEdALJLg6Uo7q5u0w1zLW9j6ipKczDyAdAHy42RNiaEaX5H86edAUhmbofGh
ZulVzHCN8lNnF1gsjilO4R2yeZvbReS4MwS1YApphI2K94AQTeBsbyRVZR+OeS70
P2DAolM9uPvdmFao8mJNDvHHpw7k8fux5euRlfdccozXs0aD8hGdXBve6eJGaWCj
MRm1UHzWgXdlTrCooD2EQH0drjE4KD8rfidNlN0h48V0LAtUbGuM28O0x05laza3
QRHXIaXsmDVhmGwyfhlpyDzCJCJlyb0IYm9m0o0ly6Ym2M5+BHTRqb44CD+yk10d
VIp7UEfd/fzwY5oNivzxJiNz/rUx2tTcD0O1miD6gsZqysepejPcvDQmGd59MgQK
w7igxedRrXzNzXX+bMDn
=3IMA
-----END PGP SIGNATURE-----

--00sTfE/IIAT5d2r5--

--===============0550294139==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Star-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/star-users

--===============0550294139==--