Re: refuse to update certain files upon extraction

[email protected] (Joerg Schilling) Tue, 18 Mar 2008 15:45:39 +0100
Newsgroups gmane.comp.archivers.star.user
Message-ID <47dfd593.ku8axIkn0xfFv0q4%[email protected]>
Lasse Kliemann <[email protected]> wrote:

> * Message by -Lasse Kliemann- from Sun 2008-03-09:
>  =

> > There was no error message (tried -vv, but not -debug). Some time passe=
d =

> > since, and I do not have those files anymore. But I found a way to repr=
oduce =

> > this, or at least something similar. How to do this is slightly complic=
ated, =

> > and I do not understand it fully myself, so I go right to the results. =
There =

> > is a level 0 dump and a level 1 dump, and a file F that changed between=
 the =

> > dumps. If the level 1 dump is extracted with 'star -xpU', then the file=
 F is =

> > restored to the state it was when the dump was taken. However, if the t=
wo =

> > dumps are extracted onto each other with 'star -xpU -restore', mysterio=
usly F =

> > is made a hardlink to some other file, and hence of course is not resto=
red to =

> > its correct state.
> > =

> > Now, the dumps are taken off from a Linux LVM filesystem snapshot. As y=
ou =

> > know, I already discovered irregularities with those (but could not yet
> > investigate it further satisfactorily due to time constraints). Would y=
ou =

> > suggest that the above problem is caused by a faulty filesystem snapsho=
t =

> > implementation, or might this be a problem in star? You may inspect the =

> > tarfiles if you wish, it's just about 2 MB; I uploaded them to =

> > =

> > 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 mad=
e a =

> > hardlink to `send-backup-test/log/supervise/pid' upon restore as descri=
bed =

> > above.

Well, I was afraid that there might have been a problem in star short time =

before star-1.5 final will be released. Fortunately it is not a star bug....

The problem is a Linux kernel bug.

Any other backup tool (like e.g. dump/restore) will run into the same probl=
em
as Linux did not update the timestamp from the directory =

"send-backup-test/log/supervise/".

You need to send a bug-report against Linux and get a fix for this problem.=
...

J=F6rg

-- =

 EMail:[email protected] (home) J=F6rg Schilling D-13353 Be=
rlin
       [email protected]                (uni)  =

       [email protected]     (work) Blog: http://schily.blogspo=
t.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/sch=
ily