I think DT should create a XMP folder in each imported picture folder.
All the XMP sidecar files should be created and saved into the XMP folder.
That would make moving your raw files around extremely difficult.
Why do you think thatâs useful?
Now at least itâs easy to get image/raw files and their associated sidecars in one view, so if you have to move them around manually, itâs doable.
With an extra subdirectory, that gets harder than needed.
And thatâs not even taking into account that most other programs expect sidecar files to be in the same directory as the parent file. Some of us rely on that detail in our workflowâŚ
I understand your concerns about moving them.
I do all my moving and arranging in Windows File Explorer before importing to DT.
The only moving I would do after the import to DT is the creation of a new folder for the tiff or jpeg exports from DT.
The Nikon software creates a sidecar folder in the root for all the sidecar files, very clean.
Hi Steve,
the current system works very well for me and I presume others. How would you propose the change needs to be implemented (as an option in preferences?). Also, you would need to convince the developers that it is worth there time to do this. Thanks for your suggestion.
I have the same opinion as @paperdigits :
I hardly ever browse my raws/exports with a file manager, just with photo manager and DT light table, I never see the relative mess you mention.
If itâs just about having an âprocessedâ or âexportedâ folder in your raw folder or elsewhere, the export module of DT can do that for you ! You can use a buch of available variables to custom the export path : darktable 4.2 user manual - variables
Is that by any chance the same software that caused you issues with file corruption?
Also, while you may not need to move files around after importing in dt, others may have toâŚ
And what do you propose to do to maintain inter-operability with other programs?
Dt doesnât create sidecar files for exported images. Any metadata are embedded in the written file (when/if possible). And anyway, âexportingâ doesnât move files around, it creates them.
yeah, I know I think I didnât make myself clear, or misunderstood @dnlyko As I though he mentioned moving to new folder the files he exports with DT from itâs file manager (thus viewing the mess at that time). Thatâs why I though helpful to specify that if he had a specific export path patern in mind he could use directly the export module to enforce it.
FWIW I use windows explorer a certain amount, and my solution to ânot seeâ the xmps is actually to either: set the folder view to group by file type - separates raws, jpgs and xmps; or, at the moment I actually have dt set to not write xmps - I just use the internal database, which I back up regularly.
Iâm not recommending this latter option though, as I may not have thought of all the ramifications!
Actually, as it turns out, Nikonâ s software did not corrupt the RAW file. It just added data to the file. DT is now aware of this and will address it in a future release.

DT is now aware of this and will address it in a future release.
Oops. Maybe I missed the point.

at the moment I actually have dt set to not write xmps - I just use the internal database, which I back up regularly.
This is a good setup to use for a secondary test installation of darktable. It avoids clobbering the xmp files you may have created with your main installation. @priort has written a lot about setting up secondary installations.
I do essentially the opposite with my main installation. I write xmp files âafter editâ and use database=:memory:
, and my backups pick up my raw, xmp, tiff and jpg files together.
Not a dt update, but rawspeed (dt uses rawspeed) that now will work around the issues that Nikon software created.

DT is now aware of this and will address it in a future release.
feel free to do the pr for that

that
There is already a merged fix for rawspeed to work with nef files that have been altered by Nikonâs software, so no action needs to be taken for that issue.