WARNING: <file> failed verification -- update discarded (will
joe at skyrush.com
Mon Dec 12 05:04:57 GMT 2005
BTW, my test case is a sending rsync version 2.6.4-3 (Fedora FC4) and a
receiving rsync 2.6.3-1 (Fedora FC3).
Within a range of 25 or so minutes of --checksum-seed values (unix time
stamps), I see the warning for 3 times.
Joe Peterson wrote:
> I just did some more testing to see if I could reproduce the warning,
> and I was successful. I tried manually setting "--checksum-seed" equal
> to timestamps around the time of the error, and I hit a case pretty
> quickly on that same file. It reproduces over and over, so it's
> definitely the first cause you list below or some other deterministic
> rsync thing.
> Now that I have a test case, would be it worth investigating? You said
> it should be rare, so I wonder if something else could be afoot and
> therefore worth checking.
> Anyway, here is the output:
> ----------- Checksum seed: 1133910002
> building file list ... done
> WARNING: 04-Let_Me_Try_Again.flac failed verification -- update
> discarded (will try again).
> (command is: rsync -av --checksum-seed=1133910002 --delete-excluded
> --exclude="*~" --exclude="#*#"
> new/The_Main_Event/04-Let_Me_Try_Again.flac host:/tmp)
> Let me know if I can help to track this down, or I could send you the
> files (new and old) in question.
> Thanks, Joe
> Wayne Davison wrote:
>>On Wed, Dec 07, 2005 at 11:38:25AM -0700, Joe Peterson wrote:
>>>failed verification -- update discarded (will try again).
>>>What does the "WARNING" imply?
>>It is telling you that the updated file that rsync created didn't match
>>the checksum that the sender told us. There are a number of different
>>ways this can happen (all of them pretty rare, but not impossible):
>>If this was an update (not a newly-created file):
>> - A block checksum may have gotten a match on some local data that
>> wasn't really identical, so the constructed file wasn't correct.
>> (The redo-pass uses a slightly different block size in order to
>> work-around such a rare occurrence.)
>> - If someone was modifying the file on the receiving side during the
>> interval between rsync generating the checksum data and the local
>> data being used to recreate the updated file, that can also cause
>> the end result to be incorrect (due to different data being copied
>> from what rsync was expecting).
>>For both updates and new files:
>> - If the sender got a read-error reading the file, the checksum is
>> forced to be invalid because this is the only current way rsync
>> has to tell the receiving side to discard the updated file.
>> (The observed behavior is not consistent with this possibility,
>> so you can ignore this one.)
>> - If the data being sent over the socket was corrupted (somehow), it
>> may be that the corruption to occurred inside the file data. This
>> is usually only possible with failing hardware, buggy networking
>> drivers, and things like that.
More information about the rsync