Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I want to make a fresh new copy of a large number of files from one local drive to another.

I've read that rsync does a checksum comparison of files when sending them to a remote machine over a network.

  1. Will rsync make the comparison when copying the files between two local drives?

  2. If it does do a verification - is it a safe bet? Or is it better to do a byte by byte comparison?

share|improve this question

4 Answers 4

up vote 24 down vote accepted

rsync always uses checksums to verify that a file was transferred correctly. If the remote file already exists, rsync may skip updating the file if the modification time and size match the source file, but if rsync decides that data needs to be transferred, checksums are always used. So if you're making a fresh copy of a file, rsync will verify that the copying process was sound.

As for the verification itself, rsync uses MD4. While long considered obsolete for secure crytographic hashes, MD4 remains adequate for checking file corruption.

Source: the man page and eyeballing the rsync source code to verify.

share|improve this answer
    
I hate to burst everyone’s bubble but rsync only does check sum verification if the -c flag is added! –  user30825 Jan 21 '13 at 21:32
9  
@clint No, the answer is correct. From the man page's explanation of the -c flag: "Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred, but that automatic after-the-transfer verification has nothing to do with this option's before-the-transfer "Does this file need to be updated?" check." –  Michael Mrozek Jan 21 '13 at 21:41
    
@Kyle Jones - so that means when rsync exits, the file is completely received? This is different from scp which just sends the data and doesn't worry about if it is fully received before exiting, right? –  David Doria Mar 18 at 14:07

rsync makes a checksum comparison before copying (in some cases), to avoid copying what's already there. The point of the checksum comparison is not to verify that the copy was successful. That's the job of the underlying infrastructure: the filesystem drivers, the disk drivers, the network drivers, etc. Individual applications such as rsync don't need to bother with this madness. All rsync needs to do (and does!) is to check the return values of system calls to make sure there was no error.

share|improve this answer

rsync does not do the post-copy verification for local file copies. You can verify that it does not by using rsync to copy a large file to a slow (i.e. USB) drive, and then copying the same file with cp, i.e.:

time rsync bigfile /mnt/usb/bigfile

time cp bigfile /mnt/usb/bigfile

Both commands take about the same amount of time, therefore rsync cannot possibly be doing the checksum—since that would involve re-reading the destination file off the slow disk.

The man page is unfortunately misleading about this. I also verified this with strace—after the copy is complete, rsync issues no read() calls on the destination file, so it cannot be checksumming it. One more you can verify it is with something like iotop: you see rsync doing read and write simultaneously (copying from source to destination), then it exits. If it were verifying integrity, there would be a read-only phase.

share|improve this answer
1  
"The man page is unfortunately misleading about this. I also verified this with strace" Did you strace the remote, running rsync process or the local one? There are two... one runs on the destination, even when you use ssh. –  user129070 May 6 '13 at 19:20
    
There is no post-copy verification for any copies, local or remote. You run rsync -c again if you want to force it to check. –  psusi May 6 '13 at 23:50

You also may use SafeFileManager. Find it at: http://mindbytez.com/sfm

It automates copy and bit to bit verify in one go.

Download the .jar file. Be sure to have installed java runtime jre7. Right click on the .jar - file, then click "open with java runtime".

share|improve this answer

protected by Community May 7 '13 at 2:47

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.