[Top][All Lists]

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

Re: [rdiff-backup-users] rdiff-backup changes .gz files

From: Robert Nichols
Subject: Re: [rdiff-backup-users] rdiff-backup changes .gz files
Date: Sun, 17 Jul 2011 18:34:01 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110621 Red Hat/3.1.11-2.el6_1 Thunderbird/3.1.11

On 07/17/2011 06:08 PM, Maarten Bezemer wrote:

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.

You misunderstand me.  All I'm saying is that the recorded checksums are
always consistent with the files that are stored in the mirror and
increments.  That indeed might not match the source files if there were
hidden changes.

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]