Set a camera to RAW+JPEG and every frame arrives as two files. Edit it in almost anything and a third appears — an .xmp sidecar carrying the keywords, captions, ratings and adjustments that could not be written into the RAW itself.

Those files are a set, and nothing in the filesystem knows it. The only thing binding them together is that they share a base name. Which means every operation that touches names — renaming, moving, writing metadata — is an operation on a relationship the operating system cannot see.

This is one of the least-documented corners of photo management, and it is where quiet data loss actually happens.

Why sidecars exist at all

RAW files are, broadly, not written into. They are a camera’s original output, formats are proprietary and numerous, and editing them in place risks corrupting a file you cannot regenerate. So the convention is to leave the RAW alone and put the metadata in a companion file next to it: IMG_4021.xmp beside IMG_4021.CR3.

DNG is the exception — it is an openly documented container designed to be written into, so metadata goes inside the file.

The upshot is that for most RAW workflows, the metadata is not in the photo. It is in a small text file that has to stay next to it, with a matching name. Break either condition and the work is gone — not corrupted, just orphaned, which is worse because nothing reports an error.

The ambiguity nobody warns you about

Here is the failure that motivated this page, and it is not hypothetical.

You shoot RAW+JPEG. The camera writes IMG_4021.CR3 and IMG_4021.JPG. Something writes a sidecar as IMG_4021.xmp. Now: which of the two files does that sidecar describe?

Nothing in the name answers it. The bare form IMG_4021.xmp is ambiguous by construction, and it gets worse with two RAW files from different cameras that happen to share a base name. Software that guesses will cheerfully show one photo’s keywords, caption and location on a different photo — and it will look completely normal.

Archyv handles this explicitly rather than guessing. It works out which file a sidecar belongs to from the file type and any ownership note the sidecar itself carries, and if it genuinely cannot tell, it refuses to use the sidecar for any of them and names the files in the run log. A gap you are told about beats a plausible wrong answer you are not. That behaviour is documented in the 1.3.4 release notes.

Two related habits it follows: when writing a sidecar of its own it uses the longer, type-qualified name — photo.nef.xmp rather than photo.xmp — so it cannot overwrite a neighbour’s, and the sidecars it writes record which file they belong to, so the question does not recur. Existing sidecars are never renamed or moved.

What renaming actually does

The reassuring part first: renaming changes only the file’s name. The image data and the metadata inside are untouched. A rename cannot degrade a photograph.

What it can do is break the set. Rename the RAW and not the JPEG and the pair no longer looks like a pair. Rename either and leave the sidecar behind and the sidecar is orphaned.

So the rule for renaming a RAW+JPEG library is: build the name from the parts the set shares. If the pattern is driven by capture date, camera and a sequence number — all properties of the frame rather than of one file — both files in a pair receive the same base name, and the set stays a set. A pattern that depends on something only one of them carries will split them.

Guides on the mechanics: renaming from the capture date and renaming from camera metadata.

Moving and copying

The same logic applies with a harder edge, because a move is not reversible by retyping a name.

Select the whole set — RAW, JPEG and sidecar — before transferring. Filtering a folder to “just the RAW files” and moving those is the single most common way a library loses its edits: the sidecars stay behind in the old folder, still perfectly valid, describing files that are no longer there.

If a transfer is organising into new folders, sort by a property of the frame — the capture date — so that both halves of a pair land in the same destination folder rather than being separated by a difference in their file dates.

Writing metadata to a pair

Writing credit or copyright across a RAW+JPEG selection does something slightly different to each half, and it is worth knowing which.

The JPEG is written in place — the fields go inside the file. The RAW gets a companion sidecar carrying the same fields, except for DNG, which is written internally. Video in the same selection gets the QuickTime Author atom plus its own XMP sidecar.

The practical consequence: after crediting a RAW shoot, your folder contains more files than it did before, and those new files are load-bearing. They are not clutter and they should not be cleaned up. See adding copyright and photographer credit for the fields involved.

“Should I just delete the JPEGs?”

Eventually most people ask this, and it is a reasonable question — the JPEGs are often redundant once the RAWs are being processed.

Two cautions. First, decide deliberately rather than by bulk-deleting an extension, because the JPEG is sometimes the file with the edits, particularly for anything that has been through a phone or a quick share. Second, a pair is not a duplicate in the ordinary sense: the two files contain genuinely different data.

Archyv’s Duplicate Detection reflects this — it groups matches as Exact Duplicate, Visual Duplicate, and Related Files, the last being RAW-plus-processed pairs specifically. They are surfaced as a distinct category rather than mixed in with true duplicates, and nothing is deleted while you browse: you mark what you want removed and commit at the end.

The short version

The set is held together by the base name and nothing else.
Sidecars in the bare name.xmp form are ambiguous when a pair shares a base name; prefer the type-qualified name.ext.xmp.
Rename from properties of the frame so both halves get the same base name.
Select the whole set before moving, or you will orphan the sidecars.
Writing metadata to RAW creates sidecars. Keep them.
A RAW+JPEG pair is not a duplicate.

Next: Metadata Renaming covers building name patterns, File Transfer covers moving sets intact, and Duplicate Detection covers how related files are grouped.