Bug #12307

Fails to load multiple sidecars for a common RAW file. Then it destructively overwrites your sidecar if you duplicate an image.

Added by Gabe Krause almost 2 years ago. Updated over 1 year ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
hardware architecture:


darktable fails to import/load more than one sidecar file when multiple sidecar files are present and associated with a common RAW file. “duplicating images” generates a copy of your history stack, stored in another XMP file and combines the duplicates as a group in lighttable. These duplicates can be independently modified. When a duplicate is created, the filename is constructed in the form “<basename>_nn.<extension>.xmp”, where nn represents the (minimum two-digit) version number of that edit.

When importing a folder with RAW file and their respective sets of darktable sidecars, any duplicates/variations are ignored and only one sidecar is loaded. All duplicates, and the work that went into them, appear to be lost. Dangerously, if we attempt to duplicate the image, it appears that our original sidecars get overwritten, destroying the work of an earlier session. This is extra bad news!

I've found one way to recover the lost work. First make sure you have a backup copy of your sidecars in a directory that's separate than the one your film roll is associated with. Then we can create a duplicate image in darktable (which will destroy your original duplicate sidecar). But then we can select the duplicated image in lighttable and load the relevant sidecar that was backed up to the separate and independent directory. Click "load sidecar file" from the lighttable history stack, with the 'overwrite' option enabled, select your backup sidecar and open it.

This recovery process exposes another, probably related, bug in darktable. When we first click "load sidecar file" in the lighttable history stack module, it opens the current film roll directory (which is convenient). But unfortunately darktable fails to show all the sidecar files in that directory. Specifically, it fails to show any sidecar that has the extension structure “<basename>_nn.<extension>.xmp” and only shows sidecars with the basic filename structure “<basename>.<extension>.xmp”. This is absurd! Especially since we can re-navigate to the same directory by clicking your hard drive in the left navigation bar. Once we click through to our film roll directory, only now does darktable list all of the sidecar files, including ones with the "_nn" filename structure.

darktable seems to have an issue recognizing its own filename construction for duplicate sidecars.

I first discovered this issue when I installed darktable on my system and tried to open a directory based film roll that was previously used by darktable (same version number). I had just temporarily uninstalled darktable from my system. The uninstall was fully executed by Revo so the reinstallation was similar to a fresh install.


#1 Updated by Gabe Krause almost 2 years ago

If you import images from the file system, images with the same base name, but different extensions (eg. IMG_1234.CR2 and IMG_1234.JPG), are supposed to form a group. As stated in the manual.
[ ]

It seems this is not working for darktable's duplicate naming structure (eg. DSC_3102.NEF.xmp and DSC_3102_01.NEF.xmp).

#2 Updated by Gabe Krause over 1 year ago

This is also an issue if a user wants to work between multiple computers. Say at home on a desktop and while traveling with a laptop.

#3 Updated by P. Schwarzl over 1 year ago

Same issue in 2.6.0 (Windows). Only the "default" Version (0) is imported.

Also available in: Atom PDF

Go to top