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