Peter Koch <bug-...@naev.de> 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:jo...@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
