How to prove a folder has not changed since last year

The question you cannot answer retrospectively

“Is this archive the same as when I put it away?” has no answer unless somebody recorded what it was. There is nothing in a file that says what it used to be.

So the work is all at the front: a manifest — path and hash, one line per file — written at a moment you are confident about. After that, checking is mechanical and takes as long as reading the tree.

It is worth doing for: archives you will not open for years, a folder of evidence or records, driver or configuration stores that should not be drifting, anything on removable media that gets carried around, and the master copy of anything you also keep backups of.

What it catches that nothing else does

Silent corruption. Storage does not only fail loudly. A bit flips, a sector degrades, a controller writes to the wrong place. A file you have not opened in three years can be quietly wrong and there is no other way to find out. This is the failure that backups make worse rather than better, because a corrupted file gets faithfully backed up over the good copies until every version is bad.

Changes nobody meant to make. A sync client that resolved a conflict in a direction nobody chose. An antivirus that quarantined and restored something. A tool that rewrote metadata across a folder. An interrupted copy that left one file short.

Whether the copy you are about to restore from is the copy you made.

Timestamps do not catch any of these. A modification time is metadata that can be preserved, restored, or set to anything.

What it cannot do

It cannot tell you why something changed, or whether it was legitimate. The output is a list of files, and you have to know what that list means.

And it proves nothing about deliberate tampering unless the manifest is somewhere the tamperer could not reach. Anyone who can rewrite the files can rewrite a manifest sitting next to them. So keep it elsewhere: a different drive, version control, a printed copy for a small enough set, or somewhere append-only.

Doing it by hand

find . -type f -exec shasum -a 256 {} + | sort > ../manifest.txt
# any time later
find . -type f -exec shasum -a 256 {} + | sort | diff - ../manifest.txt

Note the manifest goes outside the tree it describes — otherwise the next run hashes the manifest and never agrees with itself.

This works, and it stops being pleasant at scale, because diff output on thousands of lines does not distinguish a changed file from a moved one from a new one. That distinction is the whole value at that size.

Where to keep the record

• Not in the folder it describes.
• Somewhere you will still have. A manifest on the drive that failed is worth nothing.
• Version-controlled, if the tree changes legitimately. Then the history of the manifest is a history of the tree.
• Append-only, if it is ever going to be evidence. A record that can be rewritten proves what its writer wanted it to.

Re-record after every change you did mean to make, or the check becomes noise and you stop reading it — which is the usual way this practice dies.

The programs for this

• BootForge writes a manifest of every file in a tree and verifies the tree against it later, reporting what changed. Its own help says plainly that ISO mounting and writing bootable media are not implemented — this is the manifest engine, and nothing more.
• DeviceDriver seals a folder into a manifest of every file’s SHA-256 and proves months later that not one byte moved. It is strictly read-only on the folder, and explicit that it checks integrity against your own manifest rather than verifying code signatures.
• DriverGuard keeps the actual bytes as well as the hashes, so check tells you what changed and rollback can put a file back.
• PackSafe does the same for an archive split across volumes, so a piece that goes bad can be identified rather than guessed at.

Free while we are in preview, one file each, Windows and Mac. More on the checksums themselves in what a checksum proves.