WARNING: <file> failed verification -- update discarded (will try again).

Joe Peterson 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:
> Wayne,
> 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
> 04-Let_Me_Try_Again.flac
> WARNING: 04-Let_Me_Try_Again.flac failed verification -- update
> discarded (will try again).
> 04-Let_Me_Try_Again.flac
> (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:
>>>WARNING: jukebox/Frank_Sinatra/The_Main_Event/04-Let_Me_Try_Again.flac
>>>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 mailing list