[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[rdiff-backup-users] Re: Backup not identifying changed file, even thoug

From: Robert Nichols
Subject: [rdiff-backup-users] Re: Backup not identifying changed file, even though hash is different
Date: Wed, 23 Mar 2011 21:27:19 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]