Bug 233892 - kde-config CREATES .kde folder although it is expected to only return path definitions
Summary: kde-config CREATES .kde folder although it is expected to only return path de...
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: kdecore (show other bugs)
Version: 4.4
Platform: Compiled Sources Unspecified
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
Depends on:
Reported: 2010-04-09 23:35 UTC by Marko Käning
Modified: 2010-11-13 02:36 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.6


Note You need to log in before you can comment on or make changes to this bug.
Description Marko Käning 2010-04-09 23:35:25 UTC
Version:            (using Devel)
Installed from:    Compiled sources

While trying to get some kde applications build for my Mac (using MacPorts) I stumbled over the problem that kde-config actually creates the .kde directory in the user's HOME directory... (https://trac.macports.org/ticket/24403)

From kde-config's help I understood that the app should only *return* paths for configuration purposes, but _not_ create any folder itself.

	Is this assumption wrong?

See also:


The .kde creation can get actually problematic if one installs software using "sudo" without option "-H", since .kde would be created with admin user permissions in a normal user's HOME directory.

See also:


Here you see that it has been proven to be present also in kde4-config.
Comment 1 Marko Käning 2010-04-10 01:18:12 UTC
For a quick fix I simply uncommented these two lines right at the beginning of main() in kde-config.cpp.in:

(void)KGlobal::dirs(); // trigger the creation

Mind the comment "trigger the creation"!

So, the creation of the directory .kde is indeed intended...

Still, I wonder whether this is going to cause trouble for the other functions supplied by kde-config...
Comment 2 Marko Käning 2010-04-10 12:38:58 UTC
I just noticed that uncommenting the above two lines from kde-config's sources doesn't fully solve the problem, although kde-config does NOT create the folder .kde anymore!

During configure of a KDE app I noticed that the .kde folder got once again created, which indicates that there must be OTHER TOOLS AS WELL which have the same effect: i.e. creation of an empty .kde folder.


Any hints on what it could be?
Comment 3 Oswald Buddenhagen 2010-05-02 13:41:00 UTC
the behavior stems from kconfig ensuring the local config directory exists irrespective of intended action. stopping kconfig from doing it is trivial - only that it will then fail if it actually needs to write to a non-existing directory.

the cleanest solution seems to be adding an option to create missing directory components to KSaveFile. KStandardDirs::checkAccess() should also gain a mode which is fine with missing components (see KConfigIniBackend::isWritable()).
Comment 4 Marko Käning 2010-05-02 14:20:04 UTC
I think creating the directories isn't a good idea.
KDE should only check for their existence and proceed normally as long as there are no write operations necessary. If the latter are only then the directories should be created.

There is no reason why a "make build" needs to create the .kde folder in the calling user's homedir.

Thanks for diving into this matter, Oswald.
Comment 5 David Faure 2010-10-22 01:08:28 UTC
"trigger the creation" only means "the creation of the KStandardDirs object", not of the actual directory.

I fixed this, it seems to be simpler than Oswald feared. KConfig already has support for creating missing directories at saving time, in KConfigIniBackend::createEnclosing, as unittested by KConfigTest::testCreateDir(). The only spurious directory creation was from the call to saveLocation for kdeglobals in KConfigPrivate.

Proved by unittest (KConfigTest::testNoKdeHome()), but feel free to shout if I missed anything...
Comment 6 David Faure 2010-10-22 01:09:28 UTC
SVN commit 1188302 by dfaure:

Don't create $KDEHOME if it doesn't exist, and the user is just using kde4-config for instance.
BUG: 233892

 M  +1 -1      config/kconfig.cpp  
 M  +30 -10    tests/kconfigtest.cpp  
 M  +1 -0      tests/kconfigtest.h  

WebSVN link: http://websvn.kde.org/?view=rev&revision=1188302
Comment 7 Marko Käning 2010-10-22 01:21:53 UTC
Hi David,

I wonder whether these changes can be backported to KDE 3.5.10...

Comment 8 David Faure 2010-10-22 22:12:44 UTC
Probably (since you only need the one-line fix in kconfig.cpp), but KDE 3.5.x is dead, has been for years; we don't maintain it anymore, and there will be no other release anyway. Feel free to patch your local copy though.
Comment 9 Marko Käning 2010-10-22 22:25:56 UTC

I understand that you wouldn't support this version anymore.

I saw now - see below - that there are many more lines of code where saveLocation() comes into play.
(I think that all of these might need this fix.) 

I wonder whether the latest version 4.6 has this routine scattered around like the 3.5. If so, it would probably require more than just this one-line-fix of yours.

But well, I can't test it at the moment, since up to now only 3.5 runs here on my MacPorts installation.

Thanks for investigating this issue!!!



markos-imac:kdecore marko$ grep saveLocation *
kapplication.cpp:          aAutosaveDir.setPath( KGlobal::dirs()->saveLocation("tmp") );
kapplication.cpp:          aAutosaveDir.setPath( KGlobal::dirs()->saveLocation("tmp") );
kapplication.cpp:       refPath.replace(0, 4, KGlobal::dirs()->saveLocation("tmp"));
kapplication.cpp:       urlPath.replace(0, 4, KGlobal::dirs()->saveLocation("tmp"));
kconfigbackend.cpp:      mLocalFileName = KGlobal::dirs()->saveLocation(resType) + mfileName;
kconfigbackend.cpp:      mGlobalFileName = KGlobal::dirs()->saveLocation("config") +
ksimpleconfig.cpp:	saveLocation("config", QString::null, !bReadOnly)+fileName, "config", false);
kstandarddirs.cpp:QString KStandardDirs::saveLocation(const char *type,
kstandarddirs.cpp:	return inst->dirs()->saveLocation(type, QString::null, createDir) + filename;
kstandarddirs.cpp:    return inst->dirs()->saveLocation(type, dir, createDir) + file;
kstandarddirs.h:	 * @param create If set, saveLocation() will create the directories
kstandarddirs.h:	 QString saveLocation(const char *type,
ksycoca.cpp:      path = KGlobal::dirs()->saveLocation("cache") + "ksycoca";
Comment 10 David Faure 2010-10-27 18:07:02 UTC
I don't believe these other calls need the same fix.
Most of them are about actually writing data -- in which case we do need to create the directory.

In my opinion the bug is fixed, since kde4-config does not create KDEHOME anymore. Did you find a case where it still does?
Comment 11 Marko Käning 2010-10-27 22:37:54 UTC
Yes, you are right, I checked again: kde4-config doesn't create the dir.

So, I guess we'll have to hunt it down somewhere in the build process.

Thanks David, I'll come back to here once I know more.
Comment 12 Marko Käning 2010-10-27 22:37:54 UTC
Yes, you are right, I checked again: kde4-config doesn't create the dir.

So, I guess we'll have to hunt it down somewhere in the build process.

Thanks David, I'll come back to here once I know more.
Comment 13 David Faure 2010-10-27 22:47:24 UTC
Ah, build process... I see, meinproc4 could have the same issue (but a quick test says it doesn't), or kconfig_compiler (same, quick test says it's fine). Feel free to reopen this bug once you find something in the build process that creates .kde, indeed ;)
Comment 14 Marko Käning 2010-10-27 22:50:25 UTC
Yes, I'll reopen this if we find more evidence.

Actually we met the problem first when we were building and installing kde ports via MacPorts.

Only in a second step I found that kde-config itself creates the .kde folder and I thought that said program would be called during the build process...

So, perhaps you're right and the kde folder gets created by some other mechanism after all.

Perhaps I should repost this issue as .kde creation during build. What do you think?
Comment 15 David Faure 2010-10-27 23:03:30 UTC
Well kde4-config -is- called during the build, so maybe it was the only culprit.
But if it happens again, once you find out what does it, yes, reopen this bug and retitle it ;)
(or create a new one, cc me, and link to this one)
Comment 16 Marko Käning 2010-10-27 23:05:56 UTC
Will do, David, thanks for your immediate responses!
Comment 17 Marko Käning 2010-11-13 02:36:24 UTC
Hi David,

just wanted to let you know that your simple bugfix seems to have solved the issue for me.
I have made quite a few tests (http://trac.macports.org/ticket/26982) and I did not see my config dir with admin permissions since I applied your changes to the KDE sources.

I guess one can commit this patch to the official kdelibs4 port at MacPorts.

Thanks again!