Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
mkdir test
echo "hi" > test/file1
tar -c -f archive.0.tar -g test.snar test
touch -a test/file1 # changes atime and ctime, doesn't change mtime
tar -c -f archive.1.tar -g test.snar test
tar -t -G -vv -f archive.1.tar # lists Y for file1
So did GNU tar store the entire file again, even though only access time (atime) and metadata change time (ctime) were changed? This seems horribly inefficient to me, as we can reasonably expect many files to be read but not changed.
Using gtar for incremental backups is unreliable, but this is not a result of handling time stamps incorrectly.
Any backuptool that works in userland and thus cannot check internal filesystem structures as done by e.g. zfs send needs to handle time stamps the same way or it cannot grant a correct incremental backup.
atime is irrelevant for backups since it is only a hint that the file has been read, but not whether the file has been modified.
mtime may look interesting from the first view, but is irrelevant as well. This is because the mtime of a file can be set to any value by user space programs.
ctime is the only important time stamp for incremental backups as this is the only time stamp that cannot be manipulated.
As ctime cannot bemanipulated and as ctime is updated for both, content and meta data change, a backup tool needs to archive the file content and the file meta data whenever ctime has been updated.
As a result, a file that apparently did not change mtime could still have a modified content and thus needs to be in the backup
Finally: GNU tar does not implement a method, you asked for. The behavior is hard coded.
star however offers the option -dumpmeta that has been created in 2004 in order to experiment with inremental backups. star however clearly warns to use this option, see the man page:
-dumpmeta changes the behavior of star in incremental dump mode. If -dumpmeta is used and only the inode change time (st_ctime) of a file has been updated since the last incremental dump, star will archive only the meta data of the file (e.g. uid, permissions, ...) but not the file content. Using -dumpmeta will result in smaller incremental dumps, but files that have been created between two incrementals and set to an old date in st_mtime (e.g. as a result from a tar extract) will not be archived with full content. Using -dumpmeta thus may result in incomplete incremental dumps, use with extreme care.
The method used by star by default is used by ufsdump and ufsrestore from around 1981 and this is the method used by star since February 2005 and there has never been a problem with restoring incremental backups using these programs.
