Re: wrong mtime after restore

[email protected] (Joerg Schilling) Wed, 29 Aug 2007 16:15:14 +0200
Newsgroups gmane.comp.archivers.star.user
Message-ID <46d57f72.YfbUnU61AMwrnUPQ%[email protected]>
Lasse Kliemann <[email protected]> wrote:

> (...)
> > I did a second restore into a second directory. The backup comprises a level 
> > 0, 1, 2 and 5 incremental. The restore of the levels 0 to 2 give the above 
> > directory dates in the past, which presumably are correct. However the last 
> > increment, level 5, gives that directory the *current* date. That was Aug 26 
> > in my previous test, and now is Aug 28.
> > 
> > I also have a more concrete theory what could be the reason for this: the 
> > directory contains a fifo (or named pipe; created with `mknod ... p'). This 
> > fifo is frequently modified such that its mtime changes.
> > 
> > However, I still was unable to reproduce the behavior of star described above 
> > with a new incremental backup (using directories with fifos).
>
> It's actually easy. Create the fifo, make a, say, level 0 dump, then touch 
> the fifo, then do a, say, level 1 dump.
>
> Restoring the level 0 dump will give the directory containing the fifo its 
> correct date. However, restoring the level 1 dump (on top of the level 0 dump 
> of course) will give the directory in which the fifo is the *current* date.

Thank you!

It seems that the fact that star is unlinking and restoring the file
while the directory is missing in the incremental causes the problem.

It seems that I would need to change the way star extracts non-plain files.

Currently, star (as usual with -U) removes and re-rcreated the files.

I would need to check for the same file type and the same inode number.

Jörg

-- 
 EMail:[email protected] (home) Jörg Schilling D-13353 Berlin
       [email protected]                (uni)  
       [email protected]     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily