Release

Archyv 1.4.0

Your edit files now travel with your photos.

If you develop your photos in Lightroom, Capture One, DxO PhotoLab, RawTherapee or Apple Photos, your edits do not live inside the photo — they live in a separate small file sitting beside it. Archyv used to move only two kinds of those files, and only for stills. Everything else was left behind.

That meant you could rename a batch of photos and quietly lose your develop settings: the photos got new names, the edit files kept the old ones, and your editing software could no longer match them up. Videos were worse — their companion files were always left behind, and Archyv never said so.

Twenty-four kinds of edit file now travel with the photo they belong to — through renaming, sorting, transferring, and deleting a duplicate — and they come back if you undo the run.

Three things come with that:

What to do: nothing. But if you have renamed or moved photos with a previous version and your editing software has since lost track of your edits, the edit files are most likely still sitting in the original folder under the old names.

Overwriting a photo no longer strands its edits

When File Transfer was set to overwrite, it replaced the photo at the destination but left that photo’s edit file behind — now sitting beside a completely different photo that never owned it. Later, that photo could show the wrong develop settings.

The edit file now goes with the photo it belongs to, the run log names which photo it went to the Trash with, and undoing the transfer brings both back together.

A long freeze on large selections is fixed

Starting any process that writes to your files begins with a check that they are not read-only. On a large selection — particularly on a network or cloud drive — that check could stall for a very long time without finishing or reporting an error. It was measured freezing for 88 minutes on a folder of 449 files on Google Drive.

That is fixed, and the progress text during those two checking stages now says what it is actually doing in plain language.

Finding photos works on more of your metadata

Three separate problems all produced the same misleading result — a search that completed successfully and found nothing, when the photos were there:

When a search finds a photo because of a value in its companion file, the Metadata Editor now shows you that value and names the file it came from, so a match no longer looks like an empty field. Hovering the line explains it.

The list of found values beneath the search box is now labelled Filter, so it is no longer mistaken for the search box above it.

Scene is now two fields

The single Scene field was doing two unrelated jobs: holding a standard six-digit IPTC scene code on photos, and a free-text slate label such as “Reel 4 Take 2” on video. Because both were stored under the same name, reading one could show the other, and saving one could destroy the other. Video Scene Names were shown under the wrong label in Metadata Review.

They are now separate:

Both appear in the Metadata Editor, Metadata Review, Quick View, and as search filters.

What to do: if you have used Scene before, check which of the two fields your values are in. Nothing is changed on your files until you save.

Renaming and pattern editing

Other fixes

New

Release Notes, in the Help menu, opens the release-notes page so you can read what changed in any version without waiting for an update prompt.

Licences

A licence check that could not save its key no longer leaves an out-of-date key behind that could later delete a valid licence. This completes the licence persistence work that began in 1.3.5; if your licence has been forgotten in the past, that was fixed for everyone at the end of July and needed no update.

Released 8 August 2026 · Build 10