Re: [Bug-tar] more on woes with --listed-incremental

[Joerg Schilling]

"Dat Head" <address@hidden> 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:address@hidden (home) Jörg Schilling D-13353 Berlin
       address@hidden                (uni)  
       address@hidden     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily