Re: refuse to update certain files upon extraction

--===============1806155549==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="F7w+4yMapWozG0Ib"
Content-Disposition: inline


--F7w+4yMapWozG0Ib
Content-Type: multipart/mixed; boundary="WuT04sMzYDXq8et0"
Content-Disposition: inline


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

* Message by -Lasse Kliemann- from Sun 2008-03-09:
=20
> There was no error message (tried -vv, but not -debug). Some time passed=
=20
> since, and I do not have those files anymore. But I found a way to reprod=
uce=20
> this, or at least something similar. How to do this is slightly complicat=
ed,=20
> and I do not understand it fully myself, so I go right to the results. Th=
ere=20
> is a level 0 dump and a level 1 dump, and a file F that changed between t=
he=20
> dumps. If the level 1 dump is extracted with 'star -xpU', then the file F=
 is=20
> restored to the state it was when the dump was taken. However, if the two=
=20
> dumps are extracted onto each other with 'star -xpU -restore', mysterious=
ly F=20
> is made a hardlink to some other file, and hence of course is not restore=
d to=20
> its correct state.
>=20
> Now, the dumps are taken off from a Linux LVM filesystem snapshot. As you=
=20
> know, I already discovered irregularities with those (but could not yet
> investigate it further satisfactorily due to time constraints). Would you=
=20
> suggest that the above problem is caused by a faulty filesystem snapshot=
=20
> implementation, or might this be a problem in star? You may inspect the=
=20
> tarfiles if you wish, it's just about 2 MB; I uploaded them to=20
>=20
> http://unix.plastictree.net/tmp/20080309/dump0.tar
> http://unix.plastictree.net/tmp/20080309/dump1.tar
>=20
> The file to look out for is `send-backup-test/supervise/pid'. It is made =
a=20
> hardlink to `send-backup-test/log/supervise/pid' upon restore as describe=
d=20
> above.

I've tracked this thing down further, and now I have a simple way to=20
reproduce this, and it doesn't even involve snapshots. Attached is a small=
=20
program rename.c. Assume that this program is available under the command=
=20
name `rename'.=20

1. Take some empty filesystem (or an empty directory; this works with parti=
al=20
   dumps roughly as well, skip the mount steps below in that case).

   Let i=3D0.

2. Mount that filesystem read-write.

2. cd into the filesystem and call rename with two random parameters, e.g.:

  rename $RANDOM $RANDOM

3. Leave the filesystem and remount it read-only. Take a level i dump. I=20
always use '-c -acl -link-dirs -xdev -wtardumps'.

4. i=3Di+1. Goto 2 if i < 3.

Now, I have three dumps: level 0, level 1, and level 2. I restore them onto=
=20
an empty filesystem and compare with the original. Most likely, the result=
=20
will be something like this:

  a: different nlink,data,mtime
  x: different mtime
  sub/: different mtime
  sub/b: different nlink,hardlink,mtime

A closer inspection will most likely reveal that `a' and `sub/b' have the=
=20
same inode.

I've tested this on recent Linux with ext2, ext3, xfs, and reiserfs.=20

I've also tested it on SunOS 5.10, but only for the case of partial dumps=
=20
(don't have root access to Solaris machines). There is also one special thi=
ng=20
about Solaris: the call to rename must happen directly after taking the dum=
p. =20
Inserting a 'sleep 1' after the dump seems to be enough to circumvent the=
=20
problem on Solaris (at least for partial dumps). (By the way, I've found mo=
re=20
problems with such 'rapid' dumps, which I will describe separately.)

Star version is 1.5a87.

I hope there is a way to track this down to its source and fix it. If you=
=20
need more information, please ask.

Lasse


--WuT04sMzYDXq8et0
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;
}

--WuT04sMzYDXq8et0--

--F7w+4yMapWozG0Ib
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iQIcBAEBAgAGBQJH1FqUAAoJEFYll6N4nhdvDKgQAMlf5hLxm+fB1AvM63BRvmXY
SqCls6DKQd6rZb1mC7962NqsXcUmhfa0U+CjP94MNtfF0iJBKHIuyDV8rKGfPpZ7
9IlD7O2yms0SAvCq2WZcs/qrafizqv7Myy2B8JfZ0OdeU6Z8OJH24d9Ni6lMButE
zJh6nmrPitdzAEevzPNRdZIEjRuTQ1CS1SW480YMOR3jjIM3mjPKLzSI/S56bciq
hVKIr8EmdmRLupoto8/JP2EI0Nvzt/OTIPJBzAphX4Rr+1EnQt6z7+RG99lhJ35q
vKrtjsndjLh342fw3RiZ00Sa+eJ7RFuITZa6P2K0ND9wBgHYKRNffK43RMkw2oAE
L4hgvsBZgjKdIstyluDuQ6RU8yKZGZypZ3ry9xT9u9+qHGHzsAlUmBEr6R9lUfjj
IiTF8O6cFsXY4D0TU2EKokq0fXTkOpP0zsOq0+Eqp/4Mq3NGx6tRIX6SMsIvH7if
/ZX4jMSAHSbRX5PN2sXw2xcaZpbV1JhT+LbXgAQi3fzeQRNCvCHr7oRQCBP4fe/D
CU0DprcgCYV+Bl3CUE3VQ/eO64GlKdOQ6LPJukZXh90t0yyXLmUE0xW0b0eP737g
WNIufFdQxp2131wwZvirlqCg3rvMC737UozESfUUQQfUgQZhQFdJpS048VEbRrfm
DtQlEgG+5xEpDpRStm3p
=VyBx
-----END PGP SIGNATURE-----

--F7w+4yMapWozG0Ib--

--===============1806155549==
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

--===============1806155549==--