"Dat Head" <[EMAIL PROTECTED]> wrote: > dathead2 writes: > > >at some point the --listed-incremental file went from having all the > >file names in it to just the dirs (this is a good thing, as it is much > >smaller [and uses less memory]) > > would it be possible to roll gtar back to this method until the other > method is fixed?
I don't understand what you mean here. > Helmut Waitzmann wrote: > > > There may be systems, which don't update the st_ctime field when renaming > > (see rename(2)) (not linking or unlinking) a file, which is permitted by > > the Single Unix Specification. > > IMHO they should not have allowed that. There is no problem with this as long as you archive enough meta data. >From my understanding and from the tests I did run, GNU tar does not archive enough meta data in order to deal with incrementals. So far, I did never see GNU tar work correctly in case of renamed directories. I don't remember what triggers the bugs but I believe that either renaming a dir and creating another dir with the old name or renaming a dir and creating a file of the old dir name causes problems that prevent the incremental restore to restore to the correct new state. Have a look at star ftp://ftp.berlios.de/pub/star/alpha/ Star archives enough meta data to deal with these problems. As a side effect, star (in create == backup mode) only needs to remember the time of the last incremental the same way as ufsdump does. BTW: star only archives files/dirs with uptdated mtime or ctime. This makes incrementals with renamed directories small. 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 _______________________________________________ Bug-tar mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-tar
