[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: Maarten Bezemer
Subject: Re: [rdiff-backup-users] rdiff-backup changes .gz files
Date: Mon, 18 Jul 2011 01:08:23 +0200 (CEST)

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.

I'd say that changing the contents of a file and resetting the file's metadata is just asking for trouble. But maybe I'm missing the obvious and this may happen regularly, e.g. when re-building a Debian package. If that's the case, then I think this should be looked into. A lot of people are using rdiff-backup as a backup tool for Debian systems, and if this wreaks havoc on verify runs, this doesn't look good.


reply via email to

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