I’ve got myself confused about which file the darktable command line option ‘–datadir’ defines. My reading of the 4.0 manual (page 287 in my pdf version) says “Define the directory where darktable finds its runtime data. The default location depends on your installation. Typical
locations are /opt/darktable/share/darktable/ and /usr/share/darktable/.”
I naturally thought this was defining the location of the file ‘data.db’, But, as I’m having a problem with invoking dt from the command line, (details to come in a subsequent post), I’m wondering if this does not rather define the location of the file ‘darktablerc’ ? Which is correct?
If it’s the former (i.e. data.db) why doesn’t the manual provide the same guidance as for the definition of ‘library.db’: “The default location of that database file is
$HOME/.config/darktable/library.db.” In all of my Linux darktable installs, library.db and data.db have been in the same place.
Furthermore, the file darktablerc is found (in the install I’m using this morning) in both ~/.config/darktable and in /usr/share/darktable, but only the former is updated on each invocation of dt, adding to my confusion over the manual entry for --datadir
By the way neither choice seems to work today for my command line invocation of dt - but that’s for another post.
Neither. It points to darktable’s runtime data, not user data, nor user configuration data.
Did you even look at the example directories mentioned in the manual? That would have shown things like openCL kernel sources, denoise profiles, etc…
Oh, for completeness: “–datadir” does not define a file, as the name implies, it defines a (path to) a directory;
your user configuration (“darktablerc”) is stored in the directory pointed to by “–configdir”.
By default, darktable uses the same directory to store the library.db (option “–library”) as it uses for the user configuration (option “–configdir”). The file data.db is part of the user configuration, so by default it will indeed be stored in the same directory as library.db.
All in this paragraph is straight from reading the manual, no extra sources were used.
That is because darktable (like many other programs) needs at least some configuration data even on the first time it’s run by a user. At that time, ~/.config/darktable doesn’t exist yet, it’s created during that first run.
So the /usr/share/darktable/darktablerc is a startup copy, but it cannot be written to by a normal user (standard for files in /usr, see any Linux manual, or look at the file permissions)
Indeed I did look; more than that even: I read them over and over again, over a period of half a morning trying to understand why I could not invoke dt on a different portfolio of images (which worked quite well 2 months ago, when I created it). I was looking for enlightenment. It went off in another direction.
Like about 99.5% of your previous comments to my posts to this community, this comment is most helpful - it does bring the enlightenment I was seeking. The (invalid) implication that I had not bothered to read the manual arises, I think, because your knowledge set allows you to interpret the manual in a far more effective way than me. I’ve even read the ‘Program Invocation’ section again while writing this reply. It onlyprovides effective instruction in the light of your comments. For example, tThe term ‘runtime data’ is, to me, so amorphic that I was unable to determine which files (including directories in a Linux environment), where, were included. Your comment is most instructive in clarifying this.
In contrast I have found no reference in the manual to the file data.db and had no idea, prior to your comment, it was part of the user configuration data held in darktablerc. The manual does not say this. About a year ago I did find, on-line, a document from a French author, dated early 2020 I believe, which did attempt to define and explain the purpose and location of most of the files used by dt. The document described libary.db and data.db as being 2 halves of the, shall we say, ‘catalogue’ build by dt. This helped me understand why they need to be in the same location.
So I’ll mildly dispute your assertion that “All in this paragraph is straight from reading the manual, no extra sources were used.” Much of the knowledge and understanding I needed comes from reading your comments which illuminate the manual in a meaningful way for me. That is especially applicable to your explanation of the requirement for 2 copies of darktablerc, which is not mentioned - as far as I can find - in the manual (probably rightly so as the principle is generic and not specific to darktable).
In summary then, many thanks for taking the time to respond at length even though my post obviously somewhat ‘enervated’ you. My need to start dt on another catalogue is now met.
They don’t need to be in the same location (note that the --library option only points to a “library.db” file, not to a “data.db” file.
The “data.db” file contains things like user-defined styles and presets (probably a lot more stuff as well), basically more configuration items. So it’s not illogical that its location is governed by --configdir.
Oh, and I wasn’t implying you didn’t read the manual. The “look at it” part referred to looking at “/usr/share/darktable”, where there are things like “noiseprofiles.json”. Also, knowing /usr and its subdirectories are not supposed to be user-writable is fairly basic knowledge when you use Linux. It’s still an OS that needs more “hands-on” knowledge than e.g. MacOS (to avoid mentioning the other one).
The online manual has a search function. Typing “data.db” links to this page, where there is a (very short) description of the file’s function. Not immediately evident to find it, but that’s why there’s a search function, I suppose.
I have not previously used the on-line version, hence not noticed the search function. Hah, I just realised that I am accessing the 4.0 manual. darktable.org resources page doesn’t show me how to access the 4.2 version. I can edit the URL of course to get me to the 4.2 html version but this does not allow me to get a downloadable version.
OK, I find the URL for 4.2 by using the search function on this service (so I learned something!)