| Summary: | .kthemestylerc.lock is created in $TDEDIR/share/config | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Darrell <darrella> |
| Component: | other (any) | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | NEW --- | ||
| Severity: | minor | CC: | bugwatch, darrella, michele.calgaro |
| Priority: | P5 | ||
| Version: | R14.0.x [Trinity] | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Bug Depends on: | |||
| Bug Blocks: | 2968 | ||
|
Description
Darrell
2011-11-18 22:24:27 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)
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 >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.
>> 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. >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.
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. |