On 07/17/2011 12:35 PM, Arno Wagner wrote:
I have a suspicion, namely that for some reason these
files were changed by a Debian update, that then did
set the same original metadata after installing new
files. The suspicion comes from the differences being date
format changes only, no corruption at all.
So new question: Is there a way to make rdiff-backup
actually do a checksum comparison for exisitng files in
order to determine what to backup?
Better question: apparently Debian issues files with the same name and
timestamps but with different contents? I'd say that shouldn't happen.
Other question: can rdiff-backup be instructed to record and match a file's
ctime (change time, not creation time) in addition to the mtime for filesystems
that do support that?
I just tried chmod-ing a file, which changes ctime but not mtime, and indeed
rdiff-backup skipped the file.
Next, I copied (cp -a, so preserving metadata) the file to .blah, removed the
original, and renamed the .blah to original name.
Rdiff-backup then updated the directory (since it had updated mtime after file
copy and remove) but the file-under-test was still skipped.
Maybe we could check how rsync handles these cases?
Maybe we could also store & check inode number, but that wouldn't catch in-place
modifications followed by metadata resets.
On Sun, 17 Jul 2011, Robert Nichols wrote:
All that matters is that
rdiff-backup records a checksum that is consistent with the file it
_did_ back up, and that is always the case.
Given my example above, this may not always be the case. At least for most unix
file systems.