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

[Joe Peterson]

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).
>>jukebox/Frank_Sinatra/The_Main_Event/12-My_Way.flac
>>
>>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.
> 
> ..wayne..
>