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 640 - .kthemestylerc.lock is created in $TDEDIR/share/config
Summary: .kthemestylerc.lock is created in $TDEDIR/share/config
Status: NEW
Alias: None
Product: TDE
Classification: Unclassified
Component: other (any) (show other bugs)
Version: R14.0.x [Trinity]
Hardware: Other Other
: P5 minor
Assignee: Timothy Pearson
URL:
Depends on:
Blocks: 2968
  Show dependency treegraph
 
Reported: 2011-11-18 22:24 CST by Darrell
Modified: 2018-08-30 02:52 CDT (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Darrell 2011-11-18 22:24:27 CST
When using TDE as root (sue me :)), TDE creates a zero byte .kthemestylerc.lock file in $KDEDIR/share/config. This happens in 3.5.10 too so is a remnant from then.

Paper cut candidate.
Comment 1 Darrell 2012-02-14 16:16:36 CST
Some additional information to help resolve the bug.

Renaming ${PREFIX}/share/config/kthemestylerc and then starting an app from konsole results in no lock file being created but an error message of "KThemeStyle cache seems corrupt!" That error message is found in kthemestyle.cpp.

Running an strace from konsole to open an app, for example, kedit, shows the following:

access("/opt/trinity/share/config//kthemestylerc", F_OK) = 0
open("/opt/trinity/share/config//.kthemestylerc.lock", O_RDWR|O_CREAT|O_LARGEFILE, 0600) = 10
fcntl64(10, F_SETLKW64, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}, 0xbfcfc114) = 0
open("/opt/trinity/share/config//kthemestylerc", O_RDONLY|O_LARGEFILE) = 11

Running the same konsole strace as non-root results in the following difference:

open("/opt/trinity/share/config//.kthemestylerc.lock", O_RDWR|O_CREAT|O_LARGEFILE, 0600) = -1 EACCES (Permission denied)
Comment 2 Michele Calgaro 2015-07-29 06:43:58 CDT
Hi Darrell,
I do not see any .kthemestylerc.lock (or .tdethemestylerc.lock) in my system.
Can you still reproduce the same behaviour in your TDE?
If so can you post the steps?
Thanks
Comment 3 Darrell 2015-07-29 08:08:53 CDT
>If so can you post the steps?
Start any TDE app as root. Or start TDE as root. Then look for /opt/trinity/share/config/.kthemestylerc.lock.
Comment 4 Michele Calgaro 2015-07-29 18:51:45 CDT
>> I do not see any .kthemestylerc.lock (or .tdethemestylerc.lock) in my system.
> Start any TDE app as root. Or start TDE as root. 
> Then look for /opt/trinity/share/config/.kthemestylerc.lock
I started TDE as root and run Konqueror, Kate, Konsole. No .kthemestylerc.lock in $TDEDIR/share/config nor in ~/.trinity/share/config.
When I have some time I will try to investigate the source code, see if i can understand when the file is created.
Most likely the 0-byte file is created as a way to signal that something has been done. But IMO it should be located in ~/.trinity/share/config and not in $TDEDIR/share/config. In this way we would avoid the problem described in comment 1 when running as non-root.
Comment 5 Darrell 2015-07-30 22:01:01 CDT
>No .kthemestylerc.lock in $TDEDIR/share/config nor in ~/.trinity/share/config.
I tested with R14 in Fedora 21. Same results, thus the bug is not unique to Slackware. I can start a TDE app while running the MATE desktop and see the same results.

As non-root the file is created in $TDEHOME/share/config. As root the file is created in $TDEDIR/share/config.

Superficially, getting root to create the lock file in $TDEHOME/share/config rather than $TDEDIR/share/config could close the bug report. A little deeper, why is a lock file needed -- what is being locked? Is the file a throwback to the early KDE3 days? That is, does the lock file still serve a purpose?

Looks like the lock file is created at tdelibs/tdecore/tdeconfigbackend.cpp:282.
Comment 6 Darrell 2015-07-30 22:10:51 CDT
I wondered whether the desktop style played a role. I use the KDE Classic style. After changing to both Keramik and Plastik, I no longer saw the lock file in $TDEHOME/share/config. When I restored KDE Classic I again saw the file being created.

Regardless of which style I selected I needed only to start KControl and then select the Styles category to create the lock file.

Seems only certain styles create the lock file.