File checksums and content verification
A file checksum summarizes bytes for comparison with a reference, detecting a change without supplying the missing original content.
A checksum is a value calculated from data. Comparing a file's current value with a recorded reference can reveal that the input bytes changed.
This is useful after copying a media collection or checking a recovery copy. The checksum does not contain another complete film, so discovering a mismatch is different from being able to repair it.
The exact input matters
For a small, original UTF-8 example:
Input bytes: 61 62 63
Text: abc
SHA-256:
ba7816bf8f01cfea414140de5dae2223
b00361a396177a9cb410ff61f20015ad
The two displayed digest lines form one 64-hex-character value. Adding a newline changes the input and produces another value. A filename or modification timestamp is not automatically part of a content hash.
A whole-file comparison must use the same algorithm and the same byte range on both sides. Comparing a downloaded checksum for one edition with another remuxed file is not a test of whether their films look equivalent.
A reference gives the result meaning
| Reference | What a comparison can support |
|---|---|
| Recorded before the transfer | Whether the destination matches the earlier byte content |
| Trusted publisher's value | Whether the received bytes match that published artifact |
| Newly calculated on both copies | Whether the two current inputs agree under the algorithm |
| Newly calculated only on the suspect file | A baseline for later comparisons, not proof of its earlier correctness |
A cryptographic hash makes accidental equal-digest results extraordinarily unlikely for ordinary integrity checking. It does not make collisions mathematically impossible. A digest copied from an untrusted source also does not authenticate that source's intended content.
Detection needs a recovery source
If the live file and backup disagree, the hash says that the observed inputs differ. It does not independently tell you which version is intended. Retained generations, trusted manifests and application context help make that decision.
Reading every byte also consumes storage and network work. A checksum pass across a large library can compete with playback and scans. That operation provides stronger byte-content evidence than size and timestamp comparisons, at the cost of actually reading the content.
An intact checksum does not test the decoder, subtitles or library identification. A perfectly copied but unsupported media format remains unsupported. Integrity checking answers the byte-preservation question.
See Also
- Parity protection and reconstruction
- Media backups and recoverable generations
- Backup restoration: recovering a usable server