QSettings path not using system scope for path

[ocgltd]

I'm porting my app to Qt 6.5.0 and noticed something strange in regards to QSettings. (Perhaps this doesn't relate to Qt5 to Qt6 change, but I just noticed it and this used to work). Also, I'm running on AlmaLinux 9.

My code opens a QSettings file like this

s_settingsFilePtr = new QSettings(QSettings::SystemScope, "myco","myapp");

so I would expect the conf file to be opened in /etc/xdg/myco/ directory, but instead my app is opening the file as:

'/root/.config/kdedefaults/myco/myapp.conf'

almost as if the QSettings were using user scope. What is going wrong here? The environment shows variable set:

XDG_CONFIG_DIRS=/root/.config/kdedefaults:/etc/xdg:/usr/share/kde-settings/kde-profile/default/xdg

but since I'm using system scope this should NOT override the conf file location (according to docs). Note that Qt was installed by downloading the Qt Creator binary from the Qt website, so I don't think -sysconfdir flag was set/path overridden.

[ChrisW67]

Fallback Mechanism describes the search order for configuration files in QSettings. Specifying QSettings::SystemScope should indeed skip the first two user-specific locations. Locations Where Application Settings Are Stored describes where these locations are on Linux systems. The first non-user location is "each directory <dir> in $XDG_CONFIG_DIRS". Your runtime environment variable XDG_CONFIG_DIRS has its first directory as /root/.config/kdedefaults and that is indeed where your file is being accessed. /etc/xdg is the location of last resort if XDG_CONFIG_DIRS is not set.

If you specifically need to read /etc/xdg... then either unset XDG_CONFIG_DIRS or open the configuration file directly with QSettings. Bear in mind that users may never see the file in that location given that many/most desktop environments will set XDG_CONFIG_DIRS, may not include /etc/xdg or include it after another location that does exist. (this is the case with my Ubuntu environment).

PS: please tell me you are not running KDE/developing as root

[ocgltd]

I interpreted the documentation very differently, but that certainly explains it.

Yes, I'm running as root since this daemon needs root access, and I need to debug it when running. I think I could have launched QtCreator as root, but this just seemed simpler....