# The copy that was 2.5 GB short

- Link: https://jcody.com/insights/copy-that-was-short-name-and-size-not-proof/
- Published: 2026-11-10T10:36:12-05:00
- Author: Jeffrey Cody

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](https://jcody.com/ai-projects/the-two-nights/),
but the short version fits in one sentence: trust the hash, not the file name.