[rdiff-backup-users] Re: Backup not identifying changed file, even though hash is different

[Robert Nichols]

On 03/23/2011 01:42 PM, Remy Blank wrote:
> Scott Jilek wrote:
> > How does Rdiff identify changes that trigger backup?  I know the file
> > times/file size will not change since it's a fixed size 1GB container
> > and Truecrypt purposely doesn't update file timestamps, but the hash
> > will change as the contents will change.
>
> That's the problem, rdiff-backup uses the file size and mtime. Both of
> which don't change here. The same happens when you open Microsoft Excel
> files without saving them: the content changes, but Excel resets the
> mtime back to the old value.

Linux systems that use prelink have that problem for binary executables
and libraries.  The first time a new file is prelinked, data is
appended, changing the size.  Subsequent prelinks change the data, but
the size stays the same.  In all cases, the original modification time
is preserved.  Fortunately, a restored binary with an out-of-date
prelink will still run, just be a little slower to start while the
run-time linker does it's work.  So, there's no serious harm done, and
the next prelink run will clean everything up.

The place that really bites me is when I use rsync to update the offline
copy of my rdiff-backup repository.  Those two copies _have_ to match
exactly or rdiff-backup will complain about checksum errors.  What my
script has to go through to avoid using rsync's expensive "--checksum"
test on every file in the repository gets really, really ugly.

--
Bob Nichols     "NOSPAM" is really part of my email address.
                Do NOT delete it.