[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rdiff-backup-users] Update errors
From: |
Ben Escoto |
Subject: |
Re: [rdiff-backup-users] Update errors |
Date: |
Sun, 25 Dec 2005 15:12:59 -0600 |
>>>>> Charlie Strauss <address@hidden>
>>>>> wrote the following on Fri, 23 Dec 2005 12:32:09 -0700
>
> I get two kinds of error messages. One of them is an update error
> that differs from the kind discussed in the wiki (for log files and
> other rapidly changing files).
> the files causing the error are old files that have not been touched
> in months.
>
> the destination for the backup is an empty directory with no previous
> backups in it.
>
> here's some sample error messages. I get lots of these:
>
> UpdateError Clustermatic.cdr Updated mirror temp file /Volumes/big/
> cems/cems/rdiff-backup.tmp.1758 does not match source
> UpdateError DCIM/137CANON/IMG_3724_b.JPG Updated mirror temp file /
> Volumes/big/cems/cems/;068;067;073;077/137;067;065;078;079;078/rdiff-
> backup.tmp.1791 does not match source
After rdiff-backup copies a file, it checks it afterwards to see if
its metadata matches the source. If it doesn't, then an UpdateError
is raised. If those rdiff-backup.tmp.XXX files are still around, you
can "stat" them to see why they don't match the originals.
A similar problem someone had a while ago is that their filesystems
would return inconsistent time information. So if you statted a file
twice you could get two different mtimes. That's probably not your
problem, but it's the kind of thing that could lead to a lot of
UpdateErrors.
> Cannot read carbonfile information from /Users/cems/Desktop/
> Desktop_sweep/this-sign-has-sharp-edges.jpg alias
> Cannot read carbonfile information from /Users/cems/Desktop/
> Desktop_sweep/unpack.pl
> Cannot read carbonfile information from /Users/cems/Desktop/IMG_2281.JPG
This is a Mac OS X specific problem (maybe the previous one too), I'm
not sure what would cause these problems. There was a thread about
this on the mailing list a few weeks ago, but no one seemed to know.
--
Ben Escoto
pgpctq84CjJr0.pgp
Description: PGP signature