Re: refuse to update certain files upon extraction

--===============2039724957==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="vmttodhTwj0NAgWp"
Content-Disposition: inline


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

* Message by -Joerg Schilling- from Wed 2007-11-14:
> Lasse Kliemann <[email protected]> wrote:
>=20
> > What could star prevent from overwriting existing files when invoked li=
ke=20
> > that:
> >
> >    star -xpU f=3Darchive.tar
> >
> > ?
> >
> > I did some incremental dumps, restored them in a different filesystem a=
nd=20
> > compared to the original one. Level 0 is no problem. On higher levels,=
=20
> > however, certain files are not updated and hence differ from the curren=
t=20
> > original. I checked the archives, and they contain the files in questio=
n in=20
> > the correct version. But they are not extracted over the existing, outd=
ated=20
> > files! Neither when I try with -xpU, nor when I try with -xpU -restore.=
=20
> > Extracting into an empty directory works (that way I found out that the=
 files=20
> > inside of the archive are the correct ones).

(...)
> As star always writes an error message, you should start to run star from
> script(1) to fetch such messages....

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 reproduc=
e=20
this, or at least something similar. How to do this is slightly complicated=
,=20
and I do not understand it fully myself, so I go right to the results. Ther=
e=20
is a level 0 dump and a level 1 dump, and a file F that changed between the=
=20
dumps. If the level 1 dump is extracted with 'star -xpU', then the file F i=
s=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', mysteriously=
 F=20
is made a hardlink to some other file, and hence of course is not restored =
to=20
its correct state.

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

http://unix.plastictree.net/tmp/20080309/dump0.tar
http://unix.plastictree.net/tmp/20080309/dump1.tar

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 described=
=20
above.

Lasse


--vmttodhTwj0NAgWp
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iQIcBAEBAgAGBQJH0zu3AAoJEFYll6N4nhdvXhQQAIUczaodjO06irXFr2ZHmlJA
LJuuRvRw8MMm+i9OsrZ8ydpvolejDLVQaX3GYqSDdQlELowmOaxTvn/UV14H4Ye6
1mxjT/vLI+6KrGBG4X2ejocc2tbVkJfroYnZ1qTKdyzoUdTQao+uRPFWd6YjZwDa
YzF7sBesGBqrgPRXQue1IXtq6Brzprxr6MHzcBjMt4KujOYFRG+tTaks+fiypa/e
cpgLq7gcBkjWksCa7suszSe08kxB4skacLcdVp4CvLn3qOmj4S6A1IxTEm+8sCXx
ZWekjTFL3FujCU5fCeAnyQN3l6zKMeJFuGFiGgjO7RRWviMbFKq3076lAw3v/Hp+
TuV6uaRT14RSCdUsJ3/JIKEn6YCjo6eKijAA9fgKxyInG53SwRBhWVuqFq8STFsa
USHrkZ3fQP5j8Gx/w1/W5k3w8Ws9vfziicdXy9vkXnL6M6mTYxZCwiPEqCSBSWY3
9kqBxAihFaHGF4sxaTjEhrH11on+eDIkA8G/70r5Ozr2sJeBj02of2F2anE62Pmm
mdXsIWN5VYbik31wlXhe39yeDWtrNtmdOMU/qCeQJTyD+M6SkH1oWtPrre7bXBKA
RfnCCisTDYhfOKpYFe20Wfh97JINJUCeajH4u+nLxKrFBHXN6Gb4Gs+1PwqWp4mR
IQtIkUifN0fxQPgBLJb2
=gVZy
-----END PGP SIGNATURE-----

--vmttodhTwj0NAgWp--

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

--===============2039724957==--