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.. > -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html