Why moving a folder breaks your photo catalogue

You reorganised the archive on Sunday. Three folders moved from one external drive to another, the 2019 shoots went into a year folder, and everything on disk is exactly where it should be. Then you open your photo library and half of it is question marks.

The files are fine. Nothing was deleted, nothing was corrupted, and every photograph is still sitting where you put it. What broke is the catalogue’s idea of where they live — and understanding that difference is the whole of this article, because it tells you which fixes are real and which ones just move the problem to next year.

The catalogue is not looking for your photograph

It is looking for a path.

Most photo libraries store, for every image, a string like /Volumes/Archive 01/Photos/2019/Iceland/DSCF4412.RAF, and treat that string as the photograph’s identity. It is a reasonable choice: paths are unique, they are cheap to store, and reading one is instant. It works perfectly for as long as nothing moves.

The moment you move a folder, that string stops resolving. The catalogue asks the file system for it, the file system says there is nothing there, and the software has to decide what to tell you. It cannot tell you the photograph is gone, because it does not know that. It cannot tell you where the photograph went, because it never knew anything about the photograph except where it used to be. So you get a question mark, and an invitation to go and find it yourself.

Your ratings, keywords and edits are usually not lost at this point — they are still attached to the row in the database. But they are attached to a row whose address no longer resolves, and the number of clicks between you and the picture has gone from zero to “select the missing folder, wait, hope it relinks the whole subtree”.

Why the fixes feel worse than the problem

There are four ways out, and three of them are not fixes.

Relink by hand. Point the library at the new location and let it walk the subtree. This works when a whole folder moved as one piece and nothing inside it changed. It is slow on a mechanical disk, it is per-folder, and it has to be done again the next time.

Never move anything. Freeze the layout of the archive for as long as the catalogue lives. This is the strategy most people end up on, without deciding to: the library becomes a reason not to reorganise, and the folder structure you chose in 2016 outlives every good idea you have had since.

Re-import. The nuclear option. It works, and it detaches your work: the ratings and keywords in the old database belong to the old rows. Whether you lose anything depends entirely on whether that work was ever written anywhere outside that database.

Identify photographs by what they are, not by where they sit. This is the only one that ends the problem instead of postponing it, and it is not complicated. It is just a different answer to “what is this photograph?”.

Identity by content

A file has something a path does not: contents. Two files with the same bytes are the same photograph no matter which drive they are on, and a file whose bytes changed is a different photograph even if the name never moved.

Negativo identifies a photograph by the volume it lives on plus its path inside that volume, and confirms it with a hash of the file’s contents. The volume is identified by its UUID when it has one, and by its remount URL — smb://nas/Photos — when it is a network share, never by its name: two drives called “Archive” would otherwise be the same drive as far as the catalogue is concerned.

So when a folder moves, the next index pass finds a file it does not have a path for, computes its hash, and finds a row that has that hash and a path that no longer resolves. Same photograph, new address. The row is updated, your ratings stay attached to it, and nothing asks you to go and find anything.

Hashing the whole file would make this honest and unusable — a 40,000-frame archive is over a hundred gigabytes. The hash is taken over the first 64 KB, the last 64 KB and the file size, which is enough to tell two photographs apart and cheap enough to run over the whole archive. On an external SSD that pass runs at 1,200 to 1,460 files per second on a single thread. On a 7,200 RPM mechanical disk — the kind most archives actually live on — it is about 89 files per second, which is 11.2 ms per file: that is the drive head moving, not the software thinking.

Where this stops being automatic, on purpose

Two files can look identical without being the same photograph. Two camera bodies restart their frame numbering; an uncompressed RAW from the same camera is always exactly the same size. If a file moved and changed before the catalogue ever hashed it, all that is left to match on is the name, the size and the date — and those coincide more often than you would like.

Negativo will not merge two rows on that evidence. It reports them as a probable move, shows both paths, says which row would survive, and waits for a person. The reasoning is that the two mistakes are not the same size: a leftover ghost row is visible and takes a second to clear, while merging two different photographs deletes one set of ratings silently, and you find out months later when a picture is not where you expect it.

That is the same rule the rest of the app runs on. Your ratings and keywords also live in an XMP sidecar next to each file, so the catalogue can be deleted and rebuilt without losing anything but indexing time — which is the other half of not being held hostage by a database.

What this does not solve

Negativo is macOS only, and it is not an editor: no exposure slider, no crop, no presets. It does not read Lightroom or Capture One catalogues either, so this is not a migration path where you import a broken library and it heals. It walks folders and files, and it reads the sidecars that are already next to them.

And identity by content does not survive a file being re-encoded. Convert a RAW to DNG and you have made a new photograph as far as any hash is concerned. What it survives is the thing that actually happens on a Sunday afternoon: moving folders around because the way you organised the archive five years ago is not the way you think about it now.

An archive should be something you can reorganise without asking permission from the software that indexes it.