Re: [Bug-tar] unmodified files included in incremental tar if link count was changed

[Joerg Schilling]

Peter Koch <address@hidden> wrote:

> Dear Joerg:
>
> Thank's for the quick response. In the meantime I have tried
> star which I had not used before. Wonderful programm but its
> decision on which files will be included into an incremental
> backup seems to be based on the same algorithm that gtar is
> using - i.e. mtime-/ctime > date of last backup.
>
> > My guess is that tar does a stat()-call on x/f2 and notices
> > that the st_nlink-value has increased.
>
> This guess was wrong. Neither gtar nor star care about the
> st_nlink count. No wonder I could not find the
> string "st_nlink" in their sources.
>
> So my next guess is: Creating a hardlink will not only change
> the st_nlink value but the ctime-value as well. And this makes
> gtar and star believe that the file or its metadata has been
> changed. If ctime has changed there's no way to find out wether
> this was caused by a real change of the files metadata (like
> changing the ownership or permissions or acls or whatever) or
> wether just the st_nlink-value was changed.

This is how POSIX filesystem semantics is defined.

> What if I change the kernel and prevent ctime-changes if only
> st_nlink was changed?
>
> Would that have any unexpected side-effects?

This would e.g. result in non-working incremental backups.

Maybe I should add that there of course is a reason for not using mtime as a 
base for incremental backups:

Since you can set mtime to any value, you would end in backups where all files 
that have been extracted by tar or that have been copied with "cp -p" are 
missing in incremental backups.

Jörg

-- 
 EMail:address@hidden                    (home) Jörg Schilling D-13353 Berlin
    address@hidden (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'