Timeline for Does rsync verify files copied between two local drives?
Current License: CC BY-SA 3.0
26 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 22 at 22:54 | comment | added | qwr | Nowadays it's likely xxh128 unix.stackexchange.com/questions/738856/… | |
| Nov 25, 2022 at 0:35 | comment | added | Kyle Jones | @AndrewC Those checks determine whether the remote file should be updated. Checksums are used to verify transferred file contents even if you don’t specify -c. | |
| Nov 24, 2022 at 19:10 | comment | added | AndrewC | I thought the default check was file size, date , name etc unless specified otherwise, that’s is, ‘-c' the checksum check. | |
| Mar 10, 2022 at 18:14 | comment | added | midnite | At the receiver end, if it does not re-read the data, how the checksum be verified? At the sender side, checksum is calculated. Then sending [file + its checksum]. Receiver (either another harddisk or over the network) gets [file + its checksum] and write the file on to disk. The receive has to calculate the checksum of her received file, then verify her own calculation against the received checksum. Isn't it? | |
| Dec 15, 2019 at 21:07 | comment | added | cheshirekow | Almost four years later, but I somewhat agree with @ndemou. I think it would be best to preface the whole thing with a sentence that indicates "checksum always for transfer, not for disk write". I read the whole answer, and didn't realize until the comments that I misread the second paragraph. | |
| Oct 24, 2018 at 13:32 | review | Suggested edits | |||
| Oct 24, 2018 at 15:13 | |||||
| Dec 13, 2016 at 2:03 | history | edited | Kyle Jones | CC BY-SA 3.0 | overheard -> overhead |
| Jul 1, 2016 at 8:43 | comment | added | ndemou | Kyle I don't believe you answer is wrong. I already noted it's "detailed well written and technically correct" but it requires the reader to be unnecessarily focused and careful. Why cover the lack of verification of the disk data which is being questioned halfway through your answer after 117 words which repeatedly describe an other irrelevant verification process? Anyway thanks for your time and interest in this discussion. I sincerely appreciate it. | |
| Jul 1, 2016 at 4:30 | comment | added | Kyle Jones | @ndemou The answer covers the lack of verification of the disk data after it is written. The OP accepted the answer. | |
| Jun 30, 2016 at 8:36 | comment | added | ndemou | Hi Kyle, I believe the question asks: "1) when copying locally does rsync add checks to verify that the copy is identical to the original and 2) how trustworthy are these checks?". You note that rsync spawns 2 processes: one reading the original and one writing to the copy and you also note that the transfer of bytes between these processes is checksummed. But this is marginally (if at all) helpful in guaranteeing the correctness of the copy because the probability of disk related issues corrupting the data is extremely higher that the probability of CPU/RAM issues. | |
| Jun 29, 2016 at 23:27 | history | edited | Kyle Jones | CC BY-SA 3.0 | Used the word "destination" instead of "remote" to avoid the connotation that the answer only applies to copies to remote hosts. |
| Jun 29, 2016 at 23:25 | comment | added | Kyle Jones | @ndemou "Always uses checksums" means for local copies as well as remote copies. rsync's behavior isn't much different when it is copying locally; it still uses two process and uses the same protcol to communicate and transfer files between them. The processes just happen to be running on the same machine. | |
| Jun 29, 2016 at 19:38 | comment | added | ndemou | 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. | |
| S Nov 22, 2015 at 22:00 | history | suggested | CommunityBot | CC BY-SA 3.0 | Older versions use MD4, but versions 3.0.0 and beyond use MD5 |
| Nov 22, 2015 at 21:09 | review | Suggested edits | |||
| S Nov 22, 2015 at 22:00 | |||||
| May 27, 2015 at 21:10 | review | Suggested edits | |||
| May 27, 2015 at 22:23 | |||||
| Mar 24, 2015 at 22:02 | comment | added | Kyle Jones | @AndreMiller Thanks for the comment. I've updated the answer to address that issue. | |
| Mar 24, 2015 at 22:02 | history | edited | Kyle Jones | CC BY-SA 3.0 | addressed comment about network transfer check vs. checking disk write integrity |
| Mar 24, 2015 at 21:26 | comment | added | Andre Miller | 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. | |
| Jan 25, 2015 at 0:13 | history | edited | Kyle Jones | CC BY-SA 3.0 | fixed typo, added link to Wikipedia for MD4. |
| Mar 18, 2014 at 14:07 | comment | added | David Doria | @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? | |
| Jan 21, 2013 at 21:41 | comment | added | Michael Mrozek | @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." | |
| Jan 21, 2013 at 21:32 | comment | added | user30825 | I hate to burst everyone’s bubble but rsync only does check sum verification if the -c flag is added! | |
| Feb 6, 2012 at 3:42 | vote | accept | Frez | ||
| Feb 6, 2012 at 1:34 | history | edited | Kyle Jones | CC BY-SA 3.0 | added 165 characters in body |
| Feb 5, 2012 at 23:42 | history | answered | Kyle Jones | CC BY-SA 3.0 |