One of my camera originals should have been 15.21 GB. The copy on disk was 12.73 GB. It had the right name, it opened, and a name-and-size check had waved it through.
I only found it because I was doing something that felt like overkill: matching every compressed file back to the hash of its original. Two copy mismatches showed up. I widened the search and found four truncated files in total. Three of them had modification times inside the same seven-minute window, which told me one copy event had been interrupted and nobody had noticed.
What I did
I did not fix anything first. I found full copies of all four on three other disks, then wrote the replacements to temporary names, checked sha256 and modification time, and only then swapped them in, stopping at the first failure. To be sure, I had a different computer re-hash all four across the network so the server could not vouch for itself. Four for four matched.
Why this matters outside my lab
Most people verify a copy by looking at the file name and the size. That is a reasonable first glance and a terrible final answer. A file can be the right name and the wrong content. A hash is the only thing that says the bytes are the same bytes.
- Size tells you something is roughly right.
- A hash tells you it is identical.
- A hash join between a copy and its parent tells you whether anything went missing, without opening a single file.
If you have an archive that has been copied forward a few times, this is the cheapest audit you can run. I wrote up how the rest of that project went on the AI Projects pages, but the short version fits in one sentence: trust the hash, not the file name.