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 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). >>>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