A negative gets scratched. A print yellows, a slide turns magenta. Every handling leaves a mark, and time does the rest. Anyone who has worked with film knows this: keeping a picture starts with protecting it from wear.
Digital files seemed to settle the matter. A JPEG opened a thousand times is the same as on the first day. A TIFF copied from one disk to another loses no generation, the way a duplicate negative did. A RAW file does not fade in a drawer. Hence a widespread idea: a digital file doesn’t wear out, so it doesn’t need watching.
The first half of that sentence is true. The second half is not.
What doesn’t wear out, and what can still change
Opening a photograph does not damage it. Reading it, displaying it, copying it: none of this alters the original file. That is a real difference from film, and real progress.
But a file is not a picture. It is a sequence of bytes, stored on a physical medium and read by software. The image on your screen only exists as long as those bytes stay exactly the same. And several things can change them without you ever touching the file:
- the medium ages: a hard drive, an SSD, a memory card or an optical disc does not last forever. A weakening area can make part of a file unreadable, or return it wrong;
- a copy goes wrong: a cable that comes loose, an external drive ejected too early, an interrupted network transfer can leave a truncated file that still has the right name and date;
- a sync writes over it: a sync service or a backup script can replace a good file with an incomplete or damaged version, and spread the error everywhere;
- hardware or software fails: faulty memory, a power cut during a write, an application bug can write the wrong bytes.
None of these incidents announces itself. The file keeps its name, sometimes its size, its icon. The Finder does not warn you. Depending on where the damage is, an altered photograph may open with a grey band, a shifted half, wrong colours, or not open at all. It may also open normally, with a flaw nobody notices for a long time.
That is the real problem: the day you discover the damage is often long after the day it happened. In the meantime, backups may have copied the damaged file, and the last good version may have gone with the rotation of your drives.
Fixity: has the file stayed identical to itself?
Archivists have a word for this question: fixity. A “fixed” file is one that has not changed since a reference point — the moment it was received, imported or archived. It is not about image quality or file format; it is about identity. Is today’s file, byte for byte, yesterday’s file?
You cannot answer that by looking at the picture. A change of a few bytes can be invisible to the eye, and looking at thousands of images one by one is not realistic. You need an objective measure, one that can be computed and compared.
That is what a checksum is for.
The SHA-256 checksum, without the technical detail
A checksum (Obscura Vault calls it a fingerprint) is a short string of characters computed from the entire content of a file. Think of it as a signature of the content: two identical files have the same fingerprint; change a single byte and the fingerprint changes completely.
SHA-256 is the most widely used way to compute one. It is a public, standardized function (the US standard FIPS 180-4), used far beyond photography. It produces a 64-character fingerprint, something like:
9f2c… followed by sixty more characters.
You don’t need to read or remember those characters. What matters are three simple properties:
- it is always computed the same way: the same file always gives the same fingerprint, on any computer, today or in twenty years;
- it reacts to the slightest change: one modified pixel, one damaged byte, a cut-off end of file, and the fingerprint is entirely different;
- it ignores names and dates: renaming or moving a file does not change its fingerprint; only its content counts.
The principle of a fixity check follows: compute a file’s fingerprint once, keep it as the reference, recompute it later and compare. Same: the file has not moved. Different: it has changed.
One important caveat: the fingerprint tells you whether a file has changed, not why. A deliberate edit and a corruption give the same result: a different fingerprint. It is then up to you to know whether you modified that file on purpose.
Checking means reading the whole file
For the check to mean anything, one condition must hold: the file has to be read in full. Checking that it exists, that it has the right size or the right modification date is not enough. A file damaged in the middle can keep its size and its date.
That is why a real check takes time on a large photo library: every byte of every file is read. It is also why it must be regular: a check made once, three years ago, says nothing about the state of things today.
What Obscura Vault does
Obscura Vault applies these principles to a photo library on the Mac.
One fingerprint per file, taken at import. When you import a folder, Vault neither copies nor moves anything: it reads each file in full and records its SHA-256 fingerprint, along with its path and size. That fingerprint is the reference against which any alteration will be measured. The details are in the Import a folder chapter of the user guide.
Fixity audits, on demand or scheduled. An audit reads every file of a project or of the whole library again, recomputes their fingerprints and compares them with the references. You can run one whenever you like, or schedule it every week or every month; the scheduled audit runs while Vault is open. An audit that was stopped, or that could not read every file, does not push back the due date: Vault tries again instead of buying you a week of silence. Checking integrity is free.
A log that is never rewritten. Each file read adds a line to the fixity log: the date, the result, the expected fingerprint and the one observed. A new check never overwrites an old one: if a file one day stops matching, the moment it happened remains known.
Four states, never three. This is probably the most important point. After its latest check, each file is in one of these four states:
| State | What it means |
|---|---|
| Verified | The file was read in full; its fingerprint is the one from the import. It is intact as of the date of the check. |
| Altered | The file was read in full; its fingerprint has changed. It was modified or corrupted. |
| Unverifiable | The file could not be read: disk disconnected, file moved or deleted, read error. |
| Never Checked | No check has been made yet. |
Why insist on “unverifiable”? Because a disconnected disk proves nothing. It does not prove that the files on it are intact: counting them as good would hide exactly the situation in which photographs are lost without anyone knowing. Nor does it prove they are damaged: counting them as altered would lead you to restore files that are fine, and drown the real alerts. “Unverifiable” is neither good news nor bad news. It is a third answer, which Vault keeps separate, and it calls for a simple action: reconnect the disk and run the audit again.
In the same way, a file that was never checked is never counted as verified. The four numbers on the Integrity screen always add up to the whole library: nothing passes for good because nobody looked at it. The user guide’s chapter Understand the verdicts covers each case and what to do about it.
And if a file is altered?
Detecting an alteration is only worth something if you can fix it. The altered file appears in the Files to Examine list, with its project and the date of the check. If it was edited on purpose, it is a new original, to be imported as such. Otherwise it must be replaced with a healthy copy: a verified archive, a copy on another disk, an offsite copy.
This is where checking meets backing up. A backup copy is only useful if you know it is good, and if you notice in time that you need it. That is the subject of the next article.
In short
- A digital file does not wear out when opened, but its bytes can change: aging media, interrupted copies, syncs, hardware failures.
- These alterations are silent and often discovered late.
- Fixity means a file has stayed identical to itself. It is checked with a fingerprint, SHA-256 being the most common kind.
- Checking means reading every file in full, regularly, and comparing it with a reference.
- A good tool keeps “verified” apart from “unverifiable”: not having been able to look is never proof.
To go further: the Fixity checks page, the Verify integrity chapter of the user guide, and the glossary.
Next in the series: You have three copies of your photos. But do you know they are still intact?