Thank you knnknn. I was about to request the same feature for TC since long time ago. (or maybe I did ? I don't remember...)
I am astonished about all negative reactions about it...
I am also dreaming such feature for TC, but since ghisler did not already participated on this topic, I feel it bad.
In my sense, a good procedure for secure copying should be (which at this point, is theorical only, I'm not talking here about technical specs and limitations like if ignoring cache is feasable or not yet):
- user click the single checkbox to enable the secured copy method.
- file is copied normally, using regular method (cache or not, OS copy, whatever...)
- IF a crc32/md5 for the copied files was already declared somewhere (sfv/md5 file or in the tag's name), get the declared value for later use and thanks to it, decide if further checks will be done by crc32 or md5 (crc32 by default since its faster)
- calculate a crc32 OR md5 from the source file WITHOUT using cache when possible.
- If declared value existing, compare already declared crc against current source crc, then alert user if do not match.
- calculate a crc32 OR md5 from the destination file WITHOUT using cache when possible.
- alert user if crc's from source and destination do not match perfectly.
I think this should be a minimal...
And why such feature ? Let me share you my (bad) experience about it:
Months ago, I was copying files from a backup usb device destined to be formatted a bit later - a 40GB HD i guess remember - then decided to check their crc32 after the whole drive copy.
Since some years - after finding that some of my files were corrupted for remaining unknown reasons - I try to always add a crc32 to my files, then I noticed after the copy that a file wasn't matching anymore its declared crc32 value.
TC did not reported any copy error message! (for the little story, my new MB wasn't powering correctly the USB port, needing to add an second USB plug to work correctly. whatever)
That incident made me really nervous, since I avoided the lose of that file ONLY because I wasn't enough lazy and impatient to test the files byte per bytes after the drive's copy content.
Also, as you know, modern HD can reach 2TB, which means that the TC's sync tool is totally useless for instance for monthly incremental backups:
Thus, how do you check byte per byte lets say 1000 files just added in a backup HD already full at 85% without checking the whole drive each time?
It seems that fastcopy propose something in that spirit:
Verify written files data by MD5(or SHA-1. If you want to use SHA-1, write [main] Using_MD5=0 in fastcopy.ini)
... Action detail: Read(Src) -> MD5(Src) -> Write(Dst) -> Read(Dst) -> MD5(Dst) -> Compare MD5(Src/Dst) (Of course, all actions are processed in parallel as much as possible)
source:
http://www.ipmsg.org/tools/fastcopy.html.en
But as you can see, it lacking some needs, and that "(Of course, all actions are processed in parallel as much as possible)" line, makes me nervous again, since it is ambiguous (and im too lazy to check further :p).
Also, I would prefer to see that feature directly in TC, since i don't use fastcopy or TC's external copying programs.
It should not be hard to implement it, and offering easily a new USEFUL feature for TC, which is copying more safely when needed
