digiKam problem side effect - or maybe not

[rikona]

Hello Liam,

Tuesday, February 11, 2014, 4:46:11 PM, Liam wrote:

> On 11 February 2014 22:29, rikona <rikona at sonic.net> wrote:
>> Looking closer, this is a folder, user-owned, with files and
>> sub-folders in it apparently associated with the few kde pgms I use.
>> It's actually var/tmp/kdecache-rikona, and there are other folders for
>> other users including var/tmp/kdecache-root [owned by root - only has
>> icon-cache.kcache in it]]. I just left off the rikona part in my
>> original email.

> That's a crucial detail to leave off!

It probably is, I agree. I was too heavily focused on the digikam
problem and the konq effect was just a 'side effect'. I hadn't yet
looked in var/tmp and didn't remember the details fully.

>> If I remove kdecache-rikona, (1) will it mess up my other kde
>> pgms, and (2) will it be safely recreated by running those pgms [or
>> was the dir set up at install time]?

> You might lose your local settings in them. Is that a problem?

Probably not a big deal...

>> Sorry, but I tend to be a bit cautious... :-)

> Not when it comes to leaving stuff out of a problem description you
> are posting!

True - that was pilot error.... :-)

>> In the original error msg, it seemed to be complaining about
>> ownership. Is it possible that the folder kdecache-root is the
>> problem, perhaps created by running konq with sudo?
>>
>> If I change ownership of the folder kdecache-rikona to root, as it
>> seems to want, will that make the contents inaccessible to the other
>> kde pgms?

> Root can access everything. Other users can't access root's stuff.

> So, no.

I'm confused here. Let's say I run digikam [a kde pgm] as rikona. If
digikam tries to access cache, and cache is owned by root, wouldn't
that mean digikam cant see cache?

>> Is there an accessible creation-date that might tell me when these
>> dirs/files were created? That might give a clue...

> Yes. If you want to play detective, go ahead.

I was checking how to do this and it seems there is no kernel API to
access this info in linux, and thus can't be done. Is that true?

> My personal response would be: nuke 'em.

I did nuke the kdecache-rikona folder. Running gksu konq no longer
gives any error msg, but konq does not run either. Just trying gksu
konq alone did not recreate the kdecache-rikona dir either, maybe
because it didn't run. Running digikam did recreate the
kdecache-rikona folder though, owned by rikona, as before. Again
trying gksu konq with the folder there - no error msg but still
doesn't run.

Moved kdecache-root to kdecache-rootbak [just in case]. Again trying
gksu konq with no kdecache-root - no error msg but still doesn't run.
But - even though no error msgs and not running, it did create a new
kdecache-root folder, owned by root.

Changed owner of kdecache-rikona to root/0. digikam seems to run but
reports many errors in the CLI. Again trying gksu konq with owner root
- no error msg but still doesn't run. Since kdecache-rikona is now
owned by root, digikam creates a new folder kdecache-rikona2zokp,
owned by rikona - it definitely wants a cache owned by rikona!

With owner rikona, trying the no-no sudo konq does produce the error
msg as before, and gksu konq does not. With kdecache-rikona2zokp,
trying the no-no sudo konq does produce the error msg as before, but
then complains about the ownership of kdecache-rikona2zokp - and gksu
konq does not. But in no case does konq run.

So - any idea how to make gksu konq run? Or sudo konq if that is
necessary. :-) I'd really like to again be able to run konq as root...

Again, many thanks for the help

-- 

 rikona