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