Agreed. So far, the files seem to be fine once they are copied and verified to be a match. The corruption seems to be happening during the copy process, and a checksum comparison immediately after the copy finishes reveals if there was a problem or not. What I've been doing for now is copying and then running an MD5 calculator on both sides to verify. If they match, I move on with my day. If they don't, I re-copy the offending file and repeat until they do match. If FFS's verify is doing that for me, it would be wonderful to be able to skip that extra time-consuming step.It's a bit-wise comparison, so this implies the same checksum. Again, I wouldn't rely on the checksum to keep the data safe, but first find out what's wrong with the overall system.Just to be clear- verification set to ON will verify that the final copied file has the same checksum as the original?
It's a bit-wise comparison, so this implies the same checksum. Again, I wouldn't rely on the checksum to keep the data safe, but first find out what's wrong with the overall system.Just to be clear- verification set to ON will verify that the final copied file has the same checksum as the original?
Yes, I don't think this bug is on Microsoft's side. Windows does in fact error checking but this can only be as good as the underlying drivers. I suspect the symptoms you are seeing are hardware or driver related. In any case, even if Teracopy seems to be able to copy the files without errors I wouldn't trust a system with a 20% chance of data corruption to do any critical task until the root of the problem is found.Do you still think I'm trying to solve the wrong problem?