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

[Wiebe Cazemier]

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
>
> These errors are consistent - I see the same errors for the same 
> files every time I backup.  The backup finishes apparently normally, 
> with no errors listed in the session statistics.  The files that have 
> the UpdateErrors have apparently not changed since I first started 
> using rdiff-backup.  They have modification times of March 2005, or 
> earlier.  If I look in the backup directory, those files do not 
> appear.  I.e. they are not backed up.
>
> What do these errors mean?
>
> What could have caused the situation that triggers these errors?
>
> 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.
>
> Kevin Horton
> Ottawa, Canada


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.

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

signature.asc
Description: OpenPGP digital signature