I am living in that future - it’s been 20 years since I moved to digital. 
Darktable is in a lot of ways better than the four or five raw converters I have used before. So there are at least 3 sidecars to every RAW image in my archive, rarely more than five.
And no, it is not a problem once the images make it into the archive.
I don’t understand this. Each duplicate has its own sidecar. (My input is a JPG in this screenshot, but it works the same way with raw files, of course.)
When you export, you can add $(VERSION), $(VERSION.IF_MULTI) and $(VERSION.NAME) to the filename to associate the exported file with the duplicate’s version number. See darktable 4.6 user manual - variables for details.
Thanks for this. (updated post)
I can swear on my heart - that previously - I have had to manually rename *.xmp files with *_dup1.xmp to stop DT from overwriting the same *.xmp file. This was earlier this year. (I might have an alternative explanation below).
I have just done a test with my current version of DT 4.4.2 with is (supposedly) the “official” flatpack.
Under default settings for exporting - it will add an index to the end of the exported *.jpg if a file already exists but won’t name the export with any duplicate index.
When manually saving the sidecar files under DT 4.4.2 do add a duplicate index… but depending on export order - won’t match the export filename.
As installed by default - my flatpack version - doesn’t distinguish exports with duplicate indexes.
Therefore, I conclude that maybe previously - I have erroneously thought that duplicate *.xmp files were not handled - because of the insane idea that default config results in that exported *.jpg indexes follow export order while *.xmp indexes follow duplicate order? and that the file name indexes don’t distinguish between duplicate index and duplicate file index.
The default config with whatever is needed $(VERSION), $(VERSION.IF_MULTI) and $(VERSION.NAME) should automagically handle it so that duplicate index are maintained between export and sidecar. Please make it make sense.
That’s just to avoid overwriting. So, even if you export the same file with the same history, from the same ‘virtual duplicate’, the base filename is the same, and a unique number is added to resolve conflicts. That is a setting in the export module:
Additionally, you can use the variables in the file name. The default output file name is:
$(FILE_FOLDER)/darktable_exported/$(FILE_NAME) – meaning: in save with the original file name (the extension is automatic, based on the file type) in the darktable_exported subdirectory, located in the same directory where original file was. You can easily add any of the variables I mentioned above, like:
$(FILE_FOLDER)/darktable_exported/$(FILE_NAME)-v$(VERSION)-$(VERSION.NAME) would create names like IMG_20230904_123456-v2-contrastyBW.jpg if your duplicate #2 was labelled contrastyBW in the duplicate manager, and the base filename was IMG_20230904_123456.EXT.
Darktable has always done that, as far as I can remember, provided that automatic creation of sidecars is enabled.
In my case - I have to manually write a sidecar because of the readonly NAS issue.
Maybe a similar variable-based mechanism could be introduced to modify the name/location of the sidecars? But I think it’d be a rather complicated one, as it would not only affect the creation of those sidecars, but also import (it should look for sidecars based on the pattern – and what if you changed the pattern at some point?), as well as deletion and moving files using the lighttable’s selected images → move functionality. I would not hold my breath, but of course you can open a feature request.
I’m not too worried about the sidecar write location for now. If there are rainy/snowy weekends during winter - I might try to attack it myself. There doesn’t seem to be much interest in changing the status quo. I have just (in the last hour) received my new computer specifically for DT editing which includes local storage. So after a successful decade being different - I’ll be like everyone else.
However, I will raise a feature request to change the default config to honor the duplicate name/index for both export and sidecar out of the box for the default installation. It seems strange to me for someone to have to know that they need to add additional config to deal with different export and sidecar indexes? When duplicates are such a basic feature.
Also thanks @kofa for the pointers - I would not have identified the differing indexes otherwise. Thanks for making it make sense.
