[digikam] [Bug 377587] The --database-directory argument should also be the location of the digikamrc file when used

[Glenn Washburn]

https://bugs.kde.org/show_bug.cgi?id=377587

--- Comment #5 from Glenn Washburn <development at efficientek.com> ---
In my example I was making use of the checkbox config option labeled "Write to
sidecar files" in the Metadata pane of the configuration dialog.  Once
selected, a select box become enabled, where one of the options is labeled
"Write to image and to XMP Sidecar".  This option will modify the data of image
files.  So my constructed scenario was over two disjoint image sets, one where
you want the image data modified and one where you didn't.  I was attempting to
show how using a shared config you could get into a situation where you end up
modifying the image data in the image set that you did not want to modify
because you had changed the setting in DK while using the other dataset.  If
you are unaware that that config is stored in the shared config file, as
opposed to the database, you might not realize that it had been changed for the
other image set that shared that config file.  Basically it would appear as
though someone had changed that setting without your knowledge and you might
not discover this until DK had started to write to your images.  And if that's
your only set of image (bad practice, but I doubt that uncommon), then you've
just irreversibly modified your originals.  I hope that makes it a little more
clear.

I take your point about the non-obviousness of my suggestion, and I agree that
generally options should not modify other options.  It can be confusing.  I
think to help alleviate that a short sentence in the --database-directory help
text could say something like "This option changes the default config to be in
the given directory."

I think what makes this issue critical is that DK can modify your data without
you realizing it because of a non-obvious sequence of events.  I'm concerned
with anything that might modify the database or image files in a way that the
user was not-expecting and which can not easily be reversed.  My example was a
case where the images were modified, but I believe there's a case for modifying
the database when using the Maintenance tool and syncing the image metadata to
the database.  It could be overwriting data you didn't intend if you're not
checking the Metadata settings every time (because say you don't think you need
to because you didn't change it in this instance).

After looking at the config options a little more, I don't think there's a lot
of areas where this problem exists.  Its mostly related to the the Metadata
pane.  For most of the settings, its not so consequential if the value changes
without the users knowledge.

I think my suggestion is the most conservative one to take.  If the user gets
annoyed that they have to change the same config option for each DK database
instance, they'll look into using a shared config.  Its annoying and extra time
spent, but I think that's better than potential data loss.

As to your example, I think its a very valid use case.  I just don't think it
should be the default.

Also, considering that users of the --database-directory option will have been
using the user global config file.  It might make sense to copy that file (if
it exists) to the --database-directory, and then use it.  This will effectively
break the shared config behavior that currently exists, but will minimize the
impact by keeping the expected the config values.

Since, we've had the shared config be the behavior when using
--database-directory since its implementation (I presume), I wonder if anyone
has been hit by this?  But we likely would not even know this was the issue
because the user might just think this is DK corrupting things.

-- 
You are receiving this mail because:
You are the assignee for the bug.