Back in the DOS days there was a option to copy/V which copy and verified. It was slow but worth it when you really, really cared about the integrity of the files you were copying.
Windows doesn’t do that. You copy and hope to heck a random bit doesn’t get dropped here or there. Or a 1 bit doesn’t flip to a zero. You hope and pray there’s no CRC errors. Kind of scary when you’re copying a 4 Gig MKV file. That’s a lot of stray bits that can be misplaced. Especially when copying a Folder tree with over a hundred videos.
Is there a **reliable **copy & verify utility out there?
As a last resort I could use Quicksfv. But geez thats a pain for an entire folder tree with subfolders. I’ve heard Quicksfv isn’t even reliable for files over a 1 gig. The CRC checksum doesn’t calculate right or something?
There should be a reliable utility that just copies files one by one and does a checksum test to make darn sure they are good. If it runs for 8 hours thats fine too. I can kick it off and go to bed.
Does that work in Winders?
When you write data to disk, doesn’t Winders leave it in a buffer or cache for a while, until the memory space is needed for something else? And when you read a file that was recently written, if the data is still in cache, doesn’t it just read the data from the cache?
In other words, when you copy a file and attempt to verify it, it might not really re-read the data it just wrote to the disk at all, even if it says that’s what it’s doing.
I recall there was discussion of this way back in the Winders 98 days, but I haven’t followed it since. Was there ever a solution?
I knew perfectly well, that was what happened with floppy disks. (Remember floppy disks?) You could write a full floppy, and then use FC to compare the files you just wrote with the original files, and it would read the data back almost instantly – because it never really re-read the data from the floppy. For that, the solution was to remove the floppy, then stick it back in. That voided the cache, and then you really could verify the file.
Keep in mind, at a low level, the hard drive is adding additional information that will allow recovery from small errors (a single bit flipped, for example)
So if it the disk driver tells the OS at a low level the write succeeded, there is not really a reason to go back and read the data off the disk. If it’s a clanking disk, reading the data off is not going to do you any good if the disk is dying or decides to die at a later date, you will still lose the information.
SSDs have hash verification and other more complex strategies since the SSDs are expected to occasionally flip bits, due to limits in the memory technology itself.
Your best bet is to make more than 2 copies of the data. If it’s this important, 3 or more copies is that right approach. /v will not increase your odds enough to be worth it compared to making more copies.
Think about it : another copy of the data (in a different physical location) is another chance that all of the data is still available without errors.
The /v flag is an extremely tiny, tiny chance that a silent write error that flipped more than 1 bit is caught. (incredibly rare)
I was a bit nervous about moving some tv show vids from one drive to another. Some vid players will reject playing a vid if it’s the least bit corrupted.
I am going to make extra copies on DVD-r’s for archive. As well as keeping a hard drive with them on it.
Oh, that data is not even remotely important in any way. Just use the normal mechanism. Every half decent video player I have ever used will not freeze from small errors, a skip at most.