Re: [Bug-tar] Skipped files with --listed-incremental after rename

[Joerg Schilling]

>"Alex Adriaanse" <address@hidden> writes:

>> is there any better way to address this problem?

>rename has to modify the ctime of the parent directories involved.
>tar should use the parent directories' ctime to decide whether to
>dump the child files.

>If memory serves, 'star' does this a different (and better) way,
>but I haven't looked into it.

Hi,

I saw this in the web.....


Star uses the same method as ufsdump/ufsrestore, which is meta data based.

Star does not need to remember anything between incremental backups than the 
time and the level of the last backups - which is one time stamp per file 
system and dump level.

Star archives the file content and meta data if st_mtime did change and 
star archives all meta data for a file if st_ctime did change. This is a very 
simple and powerful method. BTW: it fails is somebody sets st_mtime back to a 
time before the last backup with a lower dump level. People who use ufsdump 
know this and this is a known problem for at least 25 years.

If a filesystem does not update st_ctime, then you cannot do simple meta data
based incremental backups.

If a filesystem does not update st_ctime, it breaks UNIX rules, since st_ctime 
indicates an inode change which I believe a rename(2) definitely is.


P.S. There is a plan (since one year) to add a SCHILY.dino tag as a parallel 
array to the list if directory content file names (in SCHILY.dir). The 
information in this array could be used to work around this reiser fs problem.
However, I don't plan to implement this feature in star-1.5.

If you like to understand the star backup system, you could run 

        star -c -dump ...

and look into the archive.

See: http://www.fokus.gmd.de/usr/schilling/private/star.html (general man page)
and  http://www.fokus.gmd.de/usr/schilling/private/man/star.4.html (archive 
format)


PP.S. Star supports incremental dumps since star-1.5a15 (June 2003)
        I am currently working on incremental restores, which is mostly
        writing a data base for inode numbers and file names.
        I expect a first working incremental restore implementaion in a few 
        weeks.


Jörg

-- 
 EMail:address@hidden (home) Jörg Schilling D-13353 Berlin
       address@hidden           (uni)  If you don't have iso-8859-1
       address@hidden   (work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling 
ftp://ftp.berlios.de/pub/schily