By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 293 - Kde-config Incorrectly Creates a Profile Folder in the System root directory
Summary: Kde-config Incorrectly Creates a Profile Folder in the System root directory
Status: RESOLVED FIXED
Alias: None
Product: TDE
Classification: Unclassified
Component: tdelibs (show other bugs)
Version: 3.5.13 [Trinity]
Hardware: All All
: P1 critical
Assignee: Timothy Pearson
URL:
Depends on:
Blocks:
 
Reported: 2010-10-01 16:43 CDT by Darrell
Modified: 2012-10-19 15:21 CDT (History)
3 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Darrell 2010-10-01 16:43:11 CDT 
When run in interactive mode (logged in) kde-config functions as expected. When run in non-interactive mode, such as in an rc.local or rc.shutdown script, then kde-config misbehaves.

The annoying behavior is creating a .kde* home directory in the system top level root directory.

The bug is a carry-over from KDE because the same behavior occurs in KDE 3.5.10. The only difference is that the 3.5.10 kde-config creates a /.kde directory while Trinity create /.kde3.

The directory gets get created there because in non-interactive mode the current working directory of a script usually is the top level.

To verify, run this little snippet in an rc.local or rc.shutdown script:

/bin/ls -la /
sleep 2
/usr/bin/kde-config --version
/bin/ls -la /
sleep 2

Change the kde-config parameter to --help. Same results. A /.kde3 directory get created.

Temporarily changing directories to /root in the test snippet does not help. Probably because kde-config sees no login name or ID. The only known workaround is after running kde-config to test for the existence of the new root directory.

The bug will affect anybody who runs kde-config in a script in non-interactive mode.

kde-config is supposed to be informational and not pro-active. Hence, the tool should not presumptively be creating directories.
Comment 1 Darrell 2011-03-11 13:50:50 CST 
Looks like the bug still exists in KDE4 too:

https://bugs.kde.org/show_bug.cgi?id=249217
Comment 2 Darrell 2011-03-26 17:28:14 CDT 
As this bug migrated from kde3 to kde4, perhaps the kde4 patches might succeed for kde3 too:

http://websvn.kde.org/?revision=1188302&view=revision
Discussion: https://bugs.kde.org/show_bug.cgi?id=233892
Comment 3 Darrell 2011-11-13 21:56:31 CST 
I confirm this bug still exists in 3.5.13. kde-config creates /.trinity/share/config.

Reminder: The problem occurs only when kde-config is used in non-interactive mode such as a startup or shutdown script.
Comment 4 Darrell 2011-11-29 00:10:18 CST 
Basically, the problem occurs whenever there is no $HOME environment variable. Looks like the KDE4 people quashed this bug. There are three patches:

Refer to my Comment #2 for the discussion and the three patches.

I'm no C++ programmer but I tried looking for equivalent code in kdelibs/kdecore. This is as far as I got :):

================================
diff -urN /dev/shm/kdelibs/kdecore/kconfigbackend.cpp /dev/shm/kdelibs.new/kdecore/kconfigbackend.cpp
--- /dev/shm/kdelibs/kdecore/kconfigbackend.cpp 2011-08-10 21:30:15.000000000 -0500
+++ /dev/shm/kdelibs.new/kdecore/kconfigbackend.cpp 2011-11-28 23:58:36.872270027 -0600
@@ -255,8 +255,8 @@
       mLocalFileName = KGlobal::dirs()->saveLocation(resType) + mfileName;

    if (useKDEGlobals)
-      mGlobalFileName = KGlobal::dirs()->saveLocation("config") +
-       TQString::tqfromLatin1("kdeglobals");
+      mGlobalFileName = KGlobal::dirs()->saveLocation("config", TQString(), false) +
+        TQString::tqfromLatin1("kdeglobals");
    else
       mGlobalFileName = TQString::null;
================================
Comment 5 Timothy Pearson 2012-05-14 01:34:29 CDT 
(In reply to comment #4)
> Basically, the problem occurs whenever there is no $HOME environment variable.
> Looks like the KDE4 people quashed this bug. There are three patches:
> 
> Refer to my Comment #2 for the discussion and the three patches.
> 
> I'm no C++ programmer but I tried looking for equivalent code in
> kdelibs/kdecore. This is as far as I got :):
> 
> ================================
> diff -urN /dev/shm/kdelibs/kdecore/kconfigbackend.cpp

This looks to be the equivalent file; fix committed to GIT in hash 049525e.
Comment 6 Darrell 2012-05-15 00:18:51 CDT 
Not fixed. :-(

Run "tde-config -v &>/dev/null" in any startup script that is not part of the login process, such as rc.local. Then check / and notice the .trinity directory.
Comment 7 Timothy Pearson 2012-05-15 01:11:24 CDT 
Odd, that should have fixed it according to the KDE4 bug report.

That'll teach me to close a bug report before checking functionalty... :-P
Comment 8 Darrell 2012-05-15 11:41:50 CDT 
C'est la vie. Let me know how I can help.
Comment 9 Timothy Pearson 2012-05-15 14:12:46 CDT 
This ended up being a nontrivial problem.  I needed to add the ability to force a TDE program to not request write access to its configuration files, and set tde-config to read-only mode.  This is all in GIT hash d3a9d56.

I wonder if the KDE4 bug really is fixed or not. ;-)

Tim
Comment 10 Darrell 2012-05-15 14:32:10 CDT 
If the KDE4 patch succeeded then other things must have changed too....

I'll rebuild and test again with the latest patches.
Comment 11 Darrell 2012-05-15 20:47:53 CDT 
Looks like the latest patches succeeded. No profile directory in /. Another paper cut bites the dust!

Returning status to resolved. :-)
Comment 12 Darrell 2012-05-16 22:10:14 CDT 
Darn. Reopening the bug report because the patch from GIT hash d3a9d561 causes Konqueror to crash.
Comment 13 Darrell 2012-05-17 11:19:32 CDT 
The SIGABRT is caused by not rebuilding tdeaddons. Apparently the patch in GIT hash d3a9d561 caused an ABI breakage, which requires rebuilding all tdelibs dependent packages (everything).

I'm rebuilding everything today and will report more when the run completes.
Comment 14 Timothy Pearson 2012-05-24 12:01:26 CDT 
Closing as RESOLVED FIXED, as I am unable to replicate the bug in the original report and the crashes are resolved with a rebuild of TDE.
Comment 15 Darrell 2012-05-24 14:21:54 CDT 
Yes, seems fixed now. :-)

One thought.

When I run tde-config from console and $HOME/.trinity does not yet exist, the following message is seen twice:

save location /root/.trinity/share/config doesn't exist

I am unable to find any such message in tdelibs/tdebase. The message must be created by concatenation. Granted, such a message should appear only once, during the first initialization of the profile. Nonetheless, the message could be improved so users know the source of the message when mixed with other messages in the xsession log. Perhaps add the prefix '[tde-config] to the message string.
Comment 16 Timothy Pearson 2012-05-24 14:31:43 CDT 
(In reply to comment #15)
> Yes, seems fixed now. :-)
> 
> One thought.
> 
> When I run tde-config from console and $HOME/.trinity does not yet exist, the
> following message is seen twice:
> 
> save location /root/.trinity/share/config doesn't exist
> 
> I am unable to find any such message in tdelibs/tdebase. The message must be
> created by concatenation. Granted, such a message should appear only once,
> during the first initialization of the profile. Nonetheless, the message could
> be improved so users know the source of the message when mixed with other
> messages in the xsession log. Perhaps add the prefix '[tde-config] to the
> message string.

Any TDE application can theoretically generate that message due to its location in the code.  The only way to make it easier to read would be to prefix it with the executable name for that particular application (similar to your suggestion), though I think this would probably work on Linux only.

The message string is in tdecore/kstandarddirs.cpp:1142 or so for reference.