Update errors - file does not match source
Locked
Update errors - file does not match source
 
|
Re: Update errors - file does not match source
|
|
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. _______________________________________________ rdiff-backup-users mailing list at [hidden email] http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki |
signature.asc (264 bytes)
Re: Update errors - file does not match source
|
|
>>>>> Wiebe Cazemier <[hidden email]>
This might be more difficult to implement than it first appears
>>>>> 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. 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 file). > 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 _______________________________________________ rdiff-backup-users mailing list at [hidden email] http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki |
Re: Update errors - file does not match source
|
|
On 02/23/06 04:11, Ben Escoto wrote:
> >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 >file). > > Is storing it in a queue for later processing also difficult because of this? I can image retrying a file immediatly would disrupt the pipeline, but I would guess that the queue idea doesn't give that much problems with that. But, it was only a suggestion. I could live without it. > > >>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. > _______________________________________________ rdiff-backup-users mailing list at [hidden email] http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki |
| Free forum by Nabble | Edit this page |