For a quick fix I simply uncommented these two lines right at the beginning of main() in kde-config.cpp.in:

---snip---
(void)KGlobal::dirs(); // trigger the creation
(void)KGlobal::config();
---snip---

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...

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?

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()).

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.

"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...

SVN commit 1188302 by dfaure:

Don't create $KDEHOME if it doesn't exist, and the user is just using kde4-config for instance.
FIXED-IN: 4.6
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

Hi David,

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

Greets,
Marko

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.

Hi,

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!!!

Greets,
Marko

...

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";

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?

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.

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.

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 ;)

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?

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)

Will do, David, thanks for your immediate responses!
Greets,
Marko

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!

Greets,
Marko