[Top][All Lists]

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

Re: [rdiff-backup-users] Update errors - file does not match source

From: Ben Escoto
Subject: Re: [rdiff-backup-users] Update errors - file does not match source
Date: Wed, 22 Feb 2006 21:11:26 -0600

>>>>> Wiebe Cazemier <address@hidden>
>>>>> wrote the following on Sat, 11 Feb 2006 12:48:07 +0100
> On 01/23/06 21:58, Kevin Horton wrote:
> > I'm running rdiff-backup 1.1.5 on OS X 10.4.4.  I'm getting eight 
> > errors like:
> >
> > Cannot read carbonfile information from /Users/kwh/Desktop/RV_Stuff/
> > POH archive/graphs/all-3.gp
> > UpdateError Desktop/RV_Stuff/POH archive/graphs/all-3.gp Updated 
> > mirror temp file /Volumes/Maxtor_300/bu/PowerMac/Desktop/RV_Stuff/POH 
> > archive/graphs/rdiff-backup.tmp.2 does not match source
> > I think it would be better if rdiff-backup somehow made it very clear 
> > to the user that some files were not backed up.  I picked it up by 
> > studying the output, but I would have missed them if I only looked at 
> > the number of errors at the end of the session statistics.  The fact 
> > that some files are not backed up could be very important, depending 
> > on what the files are.
> It's kind of a late reply on my part, but I agree. Your situation is
> kind of unique, because your file in question hasn't changed, but even
> under valid changed-conditions, the file is skipped during backup.
> I think that at least, rdiff-backup shouldn't just say that the file was
> changed during backup, but also that it's not backed up this run. I
> think an option to rdiff-backup like "--retries-on-file-change [number]"
> would be welcome as well, perhaps with a 2 second (or so) pause between
> each try. And, an option to queue the files which have changed for
> retrying at the end of the backup would be convinient as well, because
> an immediate retry could still result in a file-has-changed situation.
> This option could be "--queue-retry-changed-files" or something.

This might be more difficult to implement than it first appears
because of rdiff-backup's pipelined design.  At any given moment the
client and server can be processing 3 different files (e.g. the client
could be listing one directory, and patching a file in a different
directory, and the server could be computing the signature of a third

> In any case, the changed-file behaviour needs some reconsideration, in
> my opinion, to prevent data-loss.

It's not perfect, but note this is not a case of "file changing while
rdiff-backup is running".  There is some problem on Mac OS X with
reading carbonfile information, so rdiff-backup is getting OS errors
while trying to read the file's information.  Under these conditions
skipping the file seems appropriate behavior.

Ben Escoto

Attachment: pgpNMvW2KqWzP.pgp
Description: PGP signature

reply via email to

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