Does rsync verify files copied between two local drives?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
58
down vote

favorite
14












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


























    up vote
    58
    down vote

    favorite
    14












    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
























      up vote
      58
      down vote

      favorite
      14









      up vote
      58
      down vote

      favorite
      14






      14





      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














      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













      share|improve this question




      share|improve this question








      edited Feb 5 '12 at 23:05

























      asked Feb 5 '12 at 22:35









      Frez

      393135




      393135




















          3 Answers
          3






          active

          oldest

          votes

















          up vote
          67
          down vote



          accepted










          rsync always uses checksums to verify that a file was transferred correctly. If the destination 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 need to be transferred, checksums are always used on the data transferred between the sending and receiving rsync processes. This verifies that the data received are the same as the data sent with high probability, without the heavy overhead of a byte-level comparison over the network.



          Once the file data are received, rsync writes the data to the file and trusts that if the kernel indicates a successful write, the data were written without corruption to disk. rsync does not reread the data and compare against the known checksum as an additional check.



          As for the verification itself, for protocol 30 and beyond (first supported in 3.0.0), rsync uses MD5. For older protocols, the checksum used is MD4.



          While long considered obsolete for secure cryptographic hashes, MD5 and MD4 remain adequate for checking file corruption.



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






          share|improve this answer


















          • 3




            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






          • 18




            @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







          • 6




            This answer does not make it clear if it actually verifies the file after a copy. If the checksum is computed as the file is being received, then it is not a post-copy checksum and you cannot be sure that the file is written correctly. You would then need to perform an additional comparison.
            – Andre Miller
            Mar 24 '15 at 21:26






          • 3




            @AndreMiller Thanks for the comment. I've updated the answer to address that issue.
            – Kyle Jones
            Mar 24 '15 at 22:02






          • 4




            Down-voting because I don't like the fact that this answer is detailed well written and technically correct and at the same time so much off topic that it misleads readers. The problem is that the answer goes into great detail on what happens during transfer while the questioner specifically states that he cares about local copies and not network transfers. I'm pretty sure Kyle Jones didn't want to mislead anyone but this answer (IMHO) does.
            – ndemou
            Jun 29 '16 at 19:38

















          up vote
          34
          down vote













          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






          • 7




            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










          • The verification is done on the incoming stream as it goes. It's not necessary to read it back from the disk if the filesystem has confirmed it's been written.
            – OrangeDog
            Jul 11 at 15:51

















          up vote
          14
          down vote













          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
















          • 1




            This seems to contradict the accepted answer...
            – djule5
            Jan 13 '16 at 6:45






          • 1




            @djule5 In what way? The accepted answer seems to mostly be about how rsync checks transferred files, but the question, and my answer, are about local copies.
            – Gilles
            Jan 13 '16 at 10:16






          • 3




            Ok, well in that context I agree it makes more sense. So "The point of the checksum comparison is not to verify that the copy was successful" is true only for local copies; and "checksums are always used on the data transferred between the sending and receiving rsync processes" is true only for transferred copies. I find the accepted answer misleading in regard to the question and believe your answer should be the accepted one (just my 2 cents).
            – djule5
            Jan 13 '16 at 18:23










          • I still feel this answer is slightly misleading. For example, it says that the network drivers in particular verify if the copy was successful - but if you were saying that checksum comparison does not verify if the copy was successful for local only, network drivers would not come into play.
            – Ken
            Aug 7 '17 at 19:56







          • 1




            @Ken I don't understand the point you're trying to make. I suspect you misread something. The network drivers come into play only if there's a network copy. Rsync itself does a checksum comparison before doing any copy, in order to decide whether to copy. Rsync doesn't do any checksum comparison after copying (because it would be pointless: it knows what it's just copied).
            – Gilles
            Aug 7 '17 at 20:04










          protected by Community♦ May 7 '13 at 2:47



          Thank you for your interest in this question.
          Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



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














          3 Answers
          3






          active

          oldest

          votes








          3 Answers
          3






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          67
          down vote



          accepted










          rsync always uses checksums to verify that a file was transferred correctly. If the destination 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 need to be transferred, checksums are always used on the data transferred between the sending and receiving rsync processes. This verifies that the data received are the same as the data sent with high probability, without the heavy overhead of a byte-level comparison over the network.



          Once the file data are received, rsync writes the data to the file and trusts that if the kernel indicates a successful write, the data were written without corruption to disk. rsync does not reread the data and compare against the known checksum as an additional check.



          As for the verification itself, for protocol 30 and beyond (first supported in 3.0.0), rsync uses MD5. For older protocols, the checksum used is MD4.



          While long considered obsolete for secure cryptographic hashes, MD5 and MD4 remain adequate for checking file corruption.



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






          share|improve this answer


















          • 3




            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






          • 18




            @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







          • 6




            This answer does not make it clear if it actually verifies the file after a copy. If the checksum is computed as the file is being received, then it is not a post-copy checksum and you cannot be sure that the file is written correctly. You would then need to perform an additional comparison.
            – Andre Miller
            Mar 24 '15 at 21:26






          • 3




            @AndreMiller Thanks for the comment. I've updated the answer to address that issue.
            – Kyle Jones
            Mar 24 '15 at 22:02






          • 4




            Down-voting because I don't like the fact that this answer is detailed well written and technically correct and at the same time so much off topic that it misleads readers. The problem is that the answer goes into great detail on what happens during transfer while the questioner specifically states that he cares about local copies and not network transfers. I'm pretty sure Kyle Jones didn't want to mislead anyone but this answer (IMHO) does.
            – ndemou
            Jun 29 '16 at 19:38














          up vote
          67
          down vote



          accepted










          rsync always uses checksums to verify that a file was transferred correctly. If the destination 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 need to be transferred, checksums are always used on the data transferred between the sending and receiving rsync processes. This verifies that the data received are the same as the data sent with high probability, without the heavy overhead of a byte-level comparison over the network.



          Once the file data are received, rsync writes the data to the file and trusts that if the kernel indicates a successful write, the data were written without corruption to disk. rsync does not reread the data and compare against the known checksum as an additional check.



          As for the verification itself, for protocol 30 and beyond (first supported in 3.0.0), rsync uses MD5. For older protocols, the checksum used is MD4.



          While long considered obsolete for secure cryptographic hashes, MD5 and MD4 remain adequate for checking file corruption.



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






          share|improve this answer


















          • 3




            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






          • 18




            @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







          • 6




            This answer does not make it clear if it actually verifies the file after a copy. If the checksum is computed as the file is being received, then it is not a post-copy checksum and you cannot be sure that the file is written correctly. You would then need to perform an additional comparison.
            – Andre Miller
            Mar 24 '15 at 21:26






          • 3




            @AndreMiller Thanks for the comment. I've updated the answer to address that issue.
            – Kyle Jones
            Mar 24 '15 at 22:02






          • 4




            Down-voting because I don't like the fact that this answer is detailed well written and technically correct and at the same time so much off topic that it misleads readers. The problem is that the answer goes into great detail on what happens during transfer while the questioner specifically states that he cares about local copies and not network transfers. I'm pretty sure Kyle Jones didn't want to mislead anyone but this answer (IMHO) does.
            – ndemou
            Jun 29 '16 at 19:38












          up vote
          67
          down vote



          accepted







          up vote
          67
          down vote



          accepted






          rsync always uses checksums to verify that a file was transferred correctly. If the destination 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 need to be transferred, checksums are always used on the data transferred between the sending and receiving rsync processes. This verifies that the data received are the same as the data sent with high probability, without the heavy overhead of a byte-level comparison over the network.



          Once the file data are received, rsync writes the data to the file and trusts that if the kernel indicates a successful write, the data were written without corruption to disk. rsync does not reread the data and compare against the known checksum as an additional check.



          As for the verification itself, for protocol 30 and beyond (first supported in 3.0.0), rsync uses MD5. For older protocols, the checksum used is MD4.



          While long considered obsolete for secure cryptographic hashes, MD5 and MD4 remain adequate for checking file corruption.



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






          share|improve this answer














          rsync always uses checksums to verify that a file was transferred correctly. If the destination 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 need to be transferred, checksums are always used on the data transferred between the sending and receiving rsync processes. This verifies that the data received are the same as the data sent with high probability, without the heavy overhead of a byte-level comparison over the network.



          Once the file data are received, rsync writes the data to the file and trusts that if the kernel indicates a successful write, the data were written without corruption to disk. rsync does not reread the data and compare against the known checksum as an additional check.



          As for the verification itself, for protocol 30 and beyond (first supported in 3.0.0), rsync uses MD5. For older protocols, the checksum used is MD4.



          While long considered obsolete for secure cryptographic hashes, MD5 and MD4 remain adequate for checking file corruption.



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







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Dec 13 '16 at 2:03

























          answered Feb 5 '12 at 23:42









          Kyle Jones

          11.2k13048




          11.2k13048







          • 3




            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






          • 18




            @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







          • 6




            This answer does not make it clear if it actually verifies the file after a copy. If the checksum is computed as the file is being received, then it is not a post-copy checksum and you cannot be sure that the file is written correctly. You would then need to perform an additional comparison.
            – Andre Miller
            Mar 24 '15 at 21:26






          • 3




            @AndreMiller Thanks for the comment. I've updated the answer to address that issue.
            – Kyle Jones
            Mar 24 '15 at 22:02






          • 4




            Down-voting because I don't like the fact that this answer is detailed well written and technically correct and at the same time so much off topic that it misleads readers. The problem is that the answer goes into great detail on what happens during transfer while the questioner specifically states that he cares about local copies and not network transfers. I'm pretty sure Kyle Jones didn't want to mislead anyone but this answer (IMHO) does.
            – ndemou
            Jun 29 '16 at 19:38












          • 3




            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






          • 18




            @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







          • 6




            This answer does not make it clear if it actually verifies the file after a copy. If the checksum is computed as the file is being received, then it is not a post-copy checksum and you cannot be sure that the file is written correctly. You would then need to perform an additional comparison.
            – Andre Miller
            Mar 24 '15 at 21:26






          • 3




            @AndreMiller Thanks for the comment. I've updated the answer to address that issue.
            – Kyle Jones
            Mar 24 '15 at 22:02






          • 4




            Down-voting because I don't like the fact that this answer is detailed well written and technically correct and at the same time so much off topic that it misleads readers. The problem is that the answer goes into great detail on what happens during transfer while the questioner specifically states that he cares about local copies and not network transfers. I'm pretty sure Kyle Jones didn't want to mislead anyone but this answer (IMHO) does.
            – ndemou
            Jun 29 '16 at 19:38







          3




          3




          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




          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




          18




          18




          @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





          @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





          6




          6




          This answer does not make it clear if it actually verifies the file after a copy. If the checksum is computed as the file is being received, then it is not a post-copy checksum and you cannot be sure that the file is written correctly. You would then need to perform an additional comparison.
          – Andre Miller
          Mar 24 '15 at 21:26




          This answer does not make it clear if it actually verifies the file after a copy. If the checksum is computed as the file is being received, then it is not a post-copy checksum and you cannot be sure that the file is written correctly. You would then need to perform an additional comparison.
          – Andre Miller
          Mar 24 '15 at 21:26




          3




          3




          @AndreMiller Thanks for the comment. I've updated the answer to address that issue.
          – Kyle Jones
          Mar 24 '15 at 22:02




          @AndreMiller Thanks for the comment. I've updated the answer to address that issue.
          – Kyle Jones
          Mar 24 '15 at 22:02




          4




          4




          Down-voting because I don't like the fact that this answer is detailed well written and technically correct and at the same time so much off topic that it misleads readers. The problem is that the answer goes into great detail on what happens during transfer while the questioner specifically states that he cares about local copies and not network transfers. I'm pretty sure Kyle Jones didn't want to mislead anyone but this answer (IMHO) does.
          – ndemou
          Jun 29 '16 at 19:38




          Down-voting because I don't like the fact that this answer is detailed well written and technically correct and at the same time so much off topic that it misleads readers. The problem is that the answer goes into great detail on what happens during transfer while the questioner specifically states that he cares about local copies and not network transfers. I'm pretty sure Kyle Jones didn't want to mislead anyone but this answer (IMHO) does.
          – ndemou
          Jun 29 '16 at 19:38












          up vote
          34
          down vote













          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






          • 7




            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










          • The verification is done on the incoming stream as it goes. It's not necessary to read it back from the disk if the filesystem has confirmed it's been written.
            – OrangeDog
            Jul 11 at 15:51














          up vote
          34
          down vote













          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






          • 7




            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










          • The verification is done on the incoming stream as it goes. It's not necessary to read it back from the disk if the filesystem has confirmed it's been written.
            – OrangeDog
            Jul 11 at 15:51












          up vote
          34
          down vote










          up vote
          34
          down vote









          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














          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














          share|improve this answer



          share|improve this answer








          edited Mar 3 '13 at 7:45









          jasonwryan

          46.8k14127176




          46.8k14127176










          answered Mar 3 '13 at 6:37









          Felix

          34932




          34932







          • 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






          • 7




            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










          • The verification is done on the incoming stream as it goes. It's not necessary to read it back from the disk if the filesystem has confirmed it's been written.
            – OrangeDog
            Jul 11 at 15:51












          • 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






          • 7




            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










          • The verification is done on the incoming stream as it goes. It's not necessary to read it back from the disk if the filesystem has confirmed it's been written.
            – OrangeDog
            Jul 11 at 15:51







          1




          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




          "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




          7




          7




          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




          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












          The verification is done on the incoming stream as it goes. It's not necessary to read it back from the disk if the filesystem has confirmed it's been written.
          – OrangeDog
          Jul 11 at 15:51




          The verification is done on the incoming stream as it goes. It's not necessary to read it back from the disk if the filesystem has confirmed it's been written.
          – OrangeDog
          Jul 11 at 15:51










          up vote
          14
          down vote













          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
















          • 1




            This seems to contradict the accepted answer...
            – djule5
            Jan 13 '16 at 6:45






          • 1




            @djule5 In what way? The accepted answer seems to mostly be about how rsync checks transferred files, but the question, and my answer, are about local copies.
            – Gilles
            Jan 13 '16 at 10:16






          • 3




            Ok, well in that context I agree it makes more sense. So "The point of the checksum comparison is not to verify that the copy was successful" is true only for local copies; and "checksums are always used on the data transferred between the sending and receiving rsync processes" is true only for transferred copies. I find the accepted answer misleading in regard to the question and believe your answer should be the accepted one (just my 2 cents).
            – djule5
            Jan 13 '16 at 18:23










          • I still feel this answer is slightly misleading. For example, it says that the network drivers in particular verify if the copy was successful - but if you were saying that checksum comparison does not verify if the copy was successful for local only, network drivers would not come into play.
            – Ken
            Aug 7 '17 at 19:56







          • 1




            @Ken I don't understand the point you're trying to make. I suspect you misread something. The network drivers come into play only if there's a network copy. Rsync itself does a checksum comparison before doing any copy, in order to decide whether to copy. Rsync doesn't do any checksum comparison after copying (because it would be pointless: it knows what it's just copied).
            – Gilles
            Aug 7 '17 at 20:04















          up vote
          14
          down vote













          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
















          • 1




            This seems to contradict the accepted answer...
            – djule5
            Jan 13 '16 at 6:45






          • 1




            @djule5 In what way? The accepted answer seems to mostly be about how rsync checks transferred files, but the question, and my answer, are about local copies.
            – Gilles
            Jan 13 '16 at 10:16






          • 3




            Ok, well in that context I agree it makes more sense. So "The point of the checksum comparison is not to verify that the copy was successful" is true only for local copies; and "checksums are always used on the data transferred between the sending and receiving rsync processes" is true only for transferred copies. I find the accepted answer misleading in regard to the question and believe your answer should be the accepted one (just my 2 cents).
            – djule5
            Jan 13 '16 at 18:23










          • I still feel this answer is slightly misleading. For example, it says that the network drivers in particular verify if the copy was successful - but if you were saying that checksum comparison does not verify if the copy was successful for local only, network drivers would not come into play.
            – Ken
            Aug 7 '17 at 19:56







          • 1




            @Ken I don't understand the point you're trying to make. I suspect you misread something. The network drivers come into play only if there's a network copy. Rsync itself does a checksum comparison before doing any copy, in order to decide whether to copy. Rsync doesn't do any checksum comparison after copying (because it would be pointless: it knows what it's just copied).
            – Gilles
            Aug 7 '17 at 20:04













          up vote
          14
          down vote










          up vote
          14
          down vote









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












          share|improve this answer



          share|improve this answer










          answered Feb 5 '12 at 23:10









          Gilles

          506k11910021529




          506k11910021529







          • 1




            This seems to contradict the accepted answer...
            – djule5
            Jan 13 '16 at 6:45






          • 1




            @djule5 In what way? The accepted answer seems to mostly be about how rsync checks transferred files, but the question, and my answer, are about local copies.
            – Gilles
            Jan 13 '16 at 10:16






          • 3




            Ok, well in that context I agree it makes more sense. So "The point of the checksum comparison is not to verify that the copy was successful" is true only for local copies; and "checksums are always used on the data transferred between the sending and receiving rsync processes" is true only for transferred copies. I find the accepted answer misleading in regard to the question and believe your answer should be the accepted one (just my 2 cents).
            – djule5
            Jan 13 '16 at 18:23










          • I still feel this answer is slightly misleading. For example, it says that the network drivers in particular verify if the copy was successful - but if you were saying that checksum comparison does not verify if the copy was successful for local only, network drivers would not come into play.
            – Ken
            Aug 7 '17 at 19:56







          • 1




            @Ken I don't understand the point you're trying to make. I suspect you misread something. The network drivers come into play only if there's a network copy. Rsync itself does a checksum comparison before doing any copy, in order to decide whether to copy. Rsync doesn't do any checksum comparison after copying (because it would be pointless: it knows what it's just copied).
            – Gilles
            Aug 7 '17 at 20:04













          • 1




            This seems to contradict the accepted answer...
            – djule5
            Jan 13 '16 at 6:45






          • 1




            @djule5 In what way? The accepted answer seems to mostly be about how rsync checks transferred files, but the question, and my answer, are about local copies.
            – Gilles
            Jan 13 '16 at 10:16






          • 3




            Ok, well in that context I agree it makes more sense. So "The point of the checksum comparison is not to verify that the copy was successful" is true only for local copies; and "checksums are always used on the data transferred between the sending and receiving rsync processes" is true only for transferred copies. I find the accepted answer misleading in regard to the question and believe your answer should be the accepted one (just my 2 cents).
            – djule5
            Jan 13 '16 at 18:23










          • I still feel this answer is slightly misleading. For example, it says that the network drivers in particular verify if the copy was successful - but if you were saying that checksum comparison does not verify if the copy was successful for local only, network drivers would not come into play.
            – Ken
            Aug 7 '17 at 19:56







          • 1




            @Ken I don't understand the point you're trying to make. I suspect you misread something. The network drivers come into play only if there's a network copy. Rsync itself does a checksum comparison before doing any copy, in order to decide whether to copy. Rsync doesn't do any checksum comparison after copying (because it would be pointless: it knows what it's just copied).
            – Gilles
            Aug 7 '17 at 20:04








          1




          1




          This seems to contradict the accepted answer...
          – djule5
          Jan 13 '16 at 6:45




          This seems to contradict the accepted answer...
          – djule5
          Jan 13 '16 at 6:45




          1




          1




          @djule5 In what way? The accepted answer seems to mostly be about how rsync checks transferred files, but the question, and my answer, are about local copies.
          – Gilles
          Jan 13 '16 at 10:16




          @djule5 In what way? The accepted answer seems to mostly be about how rsync checks transferred files, but the question, and my answer, are about local copies.
          – Gilles
          Jan 13 '16 at 10:16




          3




          3




          Ok, well in that context I agree it makes more sense. So "The point of the checksum comparison is not to verify that the copy was successful" is true only for local copies; and "checksums are always used on the data transferred between the sending and receiving rsync processes" is true only for transferred copies. I find the accepted answer misleading in regard to the question and believe your answer should be the accepted one (just my 2 cents).
          – djule5
          Jan 13 '16 at 18:23




          Ok, well in that context I agree it makes more sense. So "The point of the checksum comparison is not to verify that the copy was successful" is true only for local copies; and "checksums are always used on the data transferred between the sending and receiving rsync processes" is true only for transferred copies. I find the accepted answer misleading in regard to the question and believe your answer should be the accepted one (just my 2 cents).
          – djule5
          Jan 13 '16 at 18:23












          I still feel this answer is slightly misleading. For example, it says that the network drivers in particular verify if the copy was successful - but if you were saying that checksum comparison does not verify if the copy was successful for local only, network drivers would not come into play.
          – Ken
          Aug 7 '17 at 19:56





          I still feel this answer is slightly misleading. For example, it says that the network drivers in particular verify if the copy was successful - but if you were saying that checksum comparison does not verify if the copy was successful for local only, network drivers would not come into play.
          – Ken
          Aug 7 '17 at 19:56





          1




          1




          @Ken I don't understand the point you're trying to make. I suspect you misread something. The network drivers come into play only if there's a network copy. Rsync itself does a checksum comparison before doing any copy, in order to decide whether to copy. Rsync doesn't do any checksum comparison after copying (because it would be pointless: it knows what it's just copied).
          – Gilles
          Aug 7 '17 at 20:04





          @Ken I don't understand the point you're trying to make. I suspect you misread something. The network drivers come into play only if there's a network copy. Rsync itself does a checksum comparison before doing any copy, in order to decide whether to copy. Rsync doesn't do any checksum comparison after copying (because it would be pointless: it knows what it's just copied).
          – Gilles
          Aug 7 '17 at 20:04






          protected by Community♦ May 7 '13 at 2:47



          Thank you for your interest in this question.
          Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



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