Better library management for darktable

I’ve been using darktable for close to 6 months now and I’m wondering why it doesn’t have proper backup/restore functionality for both the database, presets, styles and settings.

It seems that the best practice for this is to copy the library.db file to the new location and call it a day but that seems limiting.

Copying the database should be fine if all I care about is getting photos into darktable, but that breaks down quite fast if I’m dualbooting or moving the library somewhere else (to a NAS, for example).

Ideally, darktable would have something close to Steam’s library folders that specify where files are that are platform specific so that moving from one platform doesn’t break and paths would key off of that.

Another possibility is having files live on external storage (cloud, NAS…etc.) with the ability to sync local changes with these places, but that can be added later.

those DB files are just sqlite and should work cross platform. not sure why you need to make it more complex.

1 Like

regarding backup: you’re aware of darktable user manual - storage ?

2 Likes

Last I looked, the db stored the full path to tbr image. You can copy the db around, but you’ll need to adjust those paths if you’re going cross platform.

4 Likes

Last I looked, backups have very little to do with what OP wants…

Just curious, why would you dual boot (I presume Windows and Linux) and open darktable from each OS? As for backups, if you have a regular backup routine for your photos, how hard is it to have that same program backup the database and settings to your backup drive?

Because I shouldn’t have to stick to one OS if darktable itself is cross-platform, it should work with the same library on both platforms without conflicts.

I am, somehow pulling changes from XMP on one platform causes the other to think changes occurred to files that were untouched. I’m guessing timestamp problems?

It does not work that way, sorry.

In library.db darktable saves the filename in table images.filename and the corresponding path in table filmrolls.folder both linked with an id.

The naming conventions for the directory tree (starting with root) differ in Linux, MacOS, and Windows. The stored paths for the images therefore cannot be consistent across operating systems.
However, the xmp sidecar files can be used for synchronization between operating systems.

“Cross-platform” in this context means that the source code is written in a way that allows compilation for different architectures and OSes (in itself already not trivial). So you can get executables for each of the supported architectures. That doesn’t mean the generated executables can run on a different platform than the one they are compiled for.

And things like directory structure and path syntax are not something an executable can modify. So expecting that you can just take system-specific data (like file paths) from one platform and use it on another is … optimistic…

But, if you think it should be possible, you can always code the required changes and submit a pull request. Or, as a last resort, create a fork of darktable. (That’s how the whole scene-referred workflow in darktable started: someone was unhappy with the current situation and coded an improvement; he finished by creating a fork).

I think for portability between OSes, something like std::filesystem::path can be used, but I’m not a C++ programmer so can’t vouch for it.

XMP files run into a problem I’ve stated in an earlier response.

If I had the skills to code it up, this would’ve been a PR instead of a discussion.

darktable works on all these platforms, and the problem with different paths can be solved (see my previous response) but I guess someone will have to code it up.

Thank you for your suggestion anyway.

You can’t do much with X:/win/path/to/some/file.ext vs /media/some-share/path/to/some/file.ext.

If darktable required that files be placed under a fixed base path, you could use relative paths, but I would hate that. I store my usual photos on one directory, PlayRaw files go to /tmp, test files I use to experiment under a third hierarchy.

That’s why library folders are needed, those hold the platform specific bits and don’t get saved in backups while the relative paths do.

See above.