Hi, I discovered that on Windows platform, Digikam is storing it's `digikamrc` configuration in %LOCALAPPDATA%, which is wrong. %LOCALAPPDATA% is a place that is tied to the local computer and can be safely thrown away, it's the right place for cache things (like `digikam/cache`, but not for config file. For example, while connecting to a random workstation belonging to a Windows Domain %LOCALAPPDATA% would be something like "C:\Users\<username>\AppData\Local" but %APPDATA% would be something like "\\<server>\<username>\AppData". On this configuration, the backup system only have to backup %APPDATA%. On a Windows Domain setup, %APPDATA% is either available by roaming or by network drive, meaning any user can connect to any computer and recover it's own config file if this configfile is stored in %APPDATA%. It also means a computer can break and the user lost nothing. The sysadmin just put throw away the faulty computer and put a brand new one without having to copy files from the faulty computer. On the contrary, if the config file is mistakenly stored in %LOCALAPPDATA% instead of %APPDATA%, everytime an user switch its computer (because it was replaced, or because computers are not tied to one user and everyone can use every computer), this user will have to reconfigure Digikam from scratch, and of course, the user will end with as many different configurations as computer he logged in. This also means that if the drive is lost, the digikam configuration is lost. %LOCALAPPDATA% is not meant to be on backup, it's for local cache and stuff like that. %LOCALAPPDATA% is meant to store stuff that can change when user change its computer, which is not an user expects from a configuration file. So, stuff like `digikamrc` and `digkam_tagmanagerrc` must be stored in %APPDATA%. Stuff like `digikam\template.xml` (author templates) must be stored in %APPDATA%. By the way, it would be better to store author templates in database like labels are, but that's another topic. As long as this kind of stuff is not stored is database, it must be stored in %APPDATA%. Stuff like `digikam/cache` must remain in %LOCALAPPDATA%, that's the right place for that, because Domains administrator does not want to uselessly increase their backup size by storing per computer throwable temporary cache, and it would uselessly consume network and drive resources, breaking the purpose of a “local” cache.
See #382363 for the special case of `digikam\template.xml`.
linking bug 382363
Note that I noticed `showfoto` and `kdenlive` on windows are affected too. Do I have to open a bug for each software affected by this bug? This is probably a bug in a common component.
It's a bug in common component from KDE library : KF5::KXMLGUI our KConfig, i'm not 100% sure. I forward to KDE core team for analyze. Gilles Caulier
I confirm that bug also affects Krita, it's obiously a bug in a common component!
A quick lookup reveals many stuff in the whole kde tree uses `QStandardPaths::DataLocation` (which returns `%LocalAppData%` as `QStandardPaths::AppLocalDataLocation` does) or even `QStandardPaths::GenericDataLocation` that does exactly the same (and some code also uses %LocalAppData% directly) instead of `QStandardPaths::DataLocation` that returns %AppData% (added in Qt 5.4) which is the only viable option. As read there: https://doc-snapshots.qt.io/qt5-dev/qstandardpaths.html > QStandardPaths::DataLocation > Returns the same value as AppLocalDataLocation. This enumeration value is deprecated. Using AppDataLocation is preferable since on Windows, the roaming path is recommended. > QStandardPaths::AppDataLocation > Returns a directory location where persistent application data can be stored. This is an application-specific directory. To obtain a path to store data to be shared with other applications, use QStandardPaths::GenericDataLocation. The returned path is never empty. On the Windows operating system, this returns the roaming path. This enum value was added in Qt 5.4. I would said that on Windows using `AppDataLocation` is not only recommended but required since other options (DataLocation, GenericDataLocation, AppLocalDataLocation) return a directory designed to be local to a disposable computer and to not be part of the user's profile. This directory is made to be not be shared among multiple computers, to not be backed up and to be wiped out. It's a bit like writing user's configuration in /temp: it's definitely not a place to save user's configuration.
*** Bug 402346 has been marked as a duplicate of this bug. ***
Bug 402346 is not a duplicate of this. Bug 402346 is saying that digikamrc must be stored withing a digikam/ directoy whatever the parent directory is, this issue is saying the parent directory is wrong.
Perhaps Qt documentation has to be edited to say: > Beware: `QStandardPaths::DataLocation` is not doing what you think it is QStandardPaths::DataLocation never returns the DataLocation, it returns a Local Cache Location. The real DataLocation is given by QStandardPaths::AppDataLocation. For storing disposable local (to the machine) cache, software can use QStandardPaths::AppLocalDataLocation. QStandardPaths::DataLocation seems to be there just because of history, it mistakenly calls to QStandardPaths::AppLocalDataLocation which is wrong and is not what developer expects.