If you ran 'cmp' on them - check your $HISTFILE, maybe you can get (at least a few) of the filenames from there.
Main Topics
Browse All TopicsI've used rsync to copy around 300GB of data in the form of small text files, large binary executables/videos, word documents etc. Source and target are both on different md raid1 devices on the same machine. The rsync command was:
# rsync -aHxv /mnt/src/ /mnt/dst/
All seemed to work well, but then I did a quick
# diff -r /mnt/src /mnt/dst
Which showed some files that differed. Around 8-10 files, a far as I can remember. A cmp -l on such a file would always return a single byte difference, and it was always the value in the old file incremented by one:
# cmp -l /mnt/src/file.exe /mnt/dst/file.exe
82778 24 25
This seems to be quite systematic. I still have the source files, so now I did a
# rsync -caHxv /mnt/src/ /mnt/dst/
and this effectively re-transfers all the corrupted files, this time without corruption.
Rsync is supposed to check the checksum of transfered files, so how is this corruption even possible?
Is there something I have to take care of when transferring large volumes of data locally with rsync? How can I be sure that this doesn't happen again (without using -c, because this takes ages)?
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
The corrupted files were not hardlinked, no.
rsync without the -c option didn't find anything new, I ran it multiple times. That's because it only looks at some attributes like the modification timestamp and doesn't do a full checksum at every run.
The corrupted files were rather large binary files, but I didn't see any pattern in them.
Do you remember if this off-by-one byte was at the end of the file? How big is /mnt/dst/file.exe? Again, is it an actual (Windows?) executable file or just a file of binary data?
It is just so *odd* that only one byte would be off and that the byte offset would also be only 1 in a handful of files over so many megabytes (or gigabytes).
Ok, it seems the problem is not with rsync... After having a diff give me a difference in a binary file, and a second diff run didn't I let the following command run for a while:
# while true; do diff /mnt/src/somefile /mnt/dst/somefile; done
Where somefile is a file in which a difference was reported earlier, size 372 MB.
It ran for a couple of minutes without returning anything, then suddenly it started printing "Binaryfiles /mnt/src/somefile and /mnt/dst/somefile differ" for about 2 minutes (and during that time cmp -l returned: 215286618 250 251. So again a one byte difference). Then it stopped again, and cmp -l reported no difference again.
I'd say it's a hardware problem... Just not sure which part is the culprit. My guess would be the mainboard.
I wonder if you could reproduce it.
Copy just a subset of files (like a directory containing a file that didn't copy correctly before) to a new, empty directory (and don't use the '-c' flag for rsync) and see if the same corruption occurs.
If you can reproduce it, I'd file a bug with on the rsync site.
If I were you, I would have selected http:#25361130 and assigned no points, but I guess closing works, too.
Business Accounts
Answer for Membership
by: nemws1Posted on 2009-09-17 at 12:27:47ID: 25359965
Hmm.. you have -H defined to preserve hard links. Depending on the how the files were copied, if 'rsync' found the original first or the hard-link first, that would account for the very-minor difference (I think).
It would be really nice to know exactly which files where bad and if they had any hard links going to them.
Does this (with the -n)
rsync -aHxv /mnt/src/ /mnt/dst/
Report any new differences? Do don't by any chance have a list of the "bad" files?