The Paper Trail

What happens to metadata

You restore an archive, or move it to a new machine, or copy it onto a drive, and every file in it now has last week’s date. Sorted by date, six years of records are one undifferentiated block. Nothing was lost, exactly. The thing that made the pile navigable was.

This is metadata rot, and it is worth understanding because the fix is trivial in advance and laborious afterwards.

The dates a file has, and none of them are the right one

The filesystem modification time is when the bytes last changed. It is what most tools sort by, and it survives some copies and not others. Restores, archive extractions, and some sync operations reset it.

The filesystem creation time is when this particular copy came into existence — which, for a restored file, is the restore. It is not the date of the original.

Embedded metadata is inside the file rather than attached to it: the EXIF block in a photograph, which carries the capture date and often the location, or a PDF’s internal creation and modification fields. This travels with the file, which makes it far more durable than filesystem dates. It is also frequently stripped or rewritten — by image resizing, by re-saving, by tools that “optimise”, and deliberately by services that remove EXIF on upload.

The date printed on the receipt is the only one that means anything, and it is the one no mechanism maintains for you.

The gap between the last two is the entire problem. A photograph of a 14 March receipt taken on 2 April has an EXIF date of 2 April, a modification time of whenever it last moved, and a real date of 14 March that exists only as pixels in the image.

The other things that quietly disappear

Folder structure, when the tool flattens. Some exports, some uploads and some restores produce a single directory. If the only record of which month a file belonged to was the folder it sat in, that information has gone.

Notes held outside the file. Tags, coloured labels, star ratings, comments in a file manager, notes in an application’s own database. All of these are stored about the file rather than in it, and almost none of them survive leaving the system that created them. An annotation kept as an app tag is an annotation with a lifespan.

Sort order that depended on an accident. Files that happened to list correctly because they were created in order will list arbitrarily once copied.

The image quality itself, sometimes. Re-encoding a photograph on upload can cost the legibility of small print. This is not metadata, but it fails at the same moment for the same reason: a process touched the file on its way somewhere.

The practice, which is one rule

Put everything that matters into the filename or into the visible content of the file.

That is the whole of it. A filename is the most durable metadata a file has: it survives copies, restores, archive extraction, flattening, and moving between operating systems. It is not perfectly durable — some services rename on upload — but it beats every alternative by a wide margin.

Concretely:

  • The receipt’s own date goes in the filename, in a format that sorts correctly as text — year first, then month, then day. Not the capture date, not the file date. The date on the paper.
  • The vendor goes in the filename.
  • The reason goes in the filename, in two or three words. This is the field that was never on the receipt at all and it has nowhere else durable to live.
  • The amount, if you like. Useful for reconciling, and it makes a duplicate obvious.

The naming scheme and why flat beats hierarchical is the subject of finding it again; the point here is narrower. Filenames are not just a convenience for searching. They are the only annotation layer that reliably survives the operations you will perform on your archive over a decade.

Where a filename genuinely can’t hold it, put it in the file: a note typed onto a scan, a covering page, a plain-text file sitting alongside the year’s folder listing anything unusual. Plain text is the other thing that survives everything.

Keep or bin

KEEP OR BIN — where information lives

  · Receipt's real date at the front of
    the filename
                    → KEEP. Survives every copy
                      operation you will ever do.

  · Reason for the spend in the filename
                    → KEEP. It has no other durable
                      home.

  · Plain-text notes file beside the year
                    → KEEP. Readable by everything,
                      forever.

  · EXIF capture date as the record's date
                    → NOT THE DATE. It's when you took
                      the photo, and it's strippable.

  · Coloured tags or app-only labels
                    → NOT PORTABLE. Fine as a working
                      aid, never as the only copy of
                      a fact.

  · Filesystem "date created" after a
    restore
                    → BIN as evidence of anything. It
                      is the date of the restore.

  · Whether a record's date, as you have
    stated it, matters for a filing
    obligation
                    → ASK LOCALLY. Which date governs
                      varies by jurisdiction and
                      record type.

Fixing an archive that already lost it

Recoverable, partly, and worth an hour rather than a weekend.

Work newest-first, because recent files still have context you remember and because the value of a record decays with the chance of anyone asking about it.

Read the date off the image. It’s in the picture. Tedious, reliable, and the only source that’s actually correct. A batch of a hundred goes faster than expected once you stop deliberating.

Don’t try to repair what you can’t read. A file whose date is illegible and whose vendor is unidentifiable gets a filename saying so, and joins the list of things you cannot establish. That is a better outcome than a confident guess — the distinction between a record and an inference in reconstructing a year you didn’t record applies just as much to your own old files.

Then stop touching the archive. Half-renamed is worse than untouched, because you can no longer tell which convention any given file follows.

What this doesn’t settle

Whether a date you have written into a filename is authoritative for anything. Whether the original image or paper must be retained unaltered. Whether re-encoding or annotating a scan affects its acceptability. Which of a transaction’s several possible dates governs any obligation.

Those are rules, they vary by jurisdiction and record type, and they belong to your tax authority or adviser. What this page settles is the mechanical part: the information you did not write into the filename is information you are relying on a copy operation to preserve, and copy operations do not consider that their job.

digitalbackups