Bug 70533 - konqueror lose file association
Summary: konqueror lose file association
Status: RESOLVED NOT A BUG
Alias: None
Product: konqueror
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Mandrake RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
: 60566 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-12-15 21:47 UTC by Yann
Modified: 2005-05-20 17:03 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yann 2003-12-15 21:47:38 UTC
Version:            (using KDE KDE 3.1.3)
Installed from:    Mandrake RPMs

This bug is not 100% reproductible.
Here is a description : in Konqueror, I associate files with applications, such as .jpg files to gqview. Then everything works fine, a single left clic on any .jpg file opens gqview with this file.
But this association is lost. Never during the same KDE session, and not always at the next one. Sometimes the setting stays for days, but it always disappears at the end.
I could not find a single event which make kde lose this file association. It is not specific to a file type. This bug was already present in the KDE shipped with Mandrake 9.1.
Comment 1 Richard 2004-08-24 10:43:31 UTC
This bug is present in Mandrake 10 Official with KDE 3.2 too. File associations set up by Mandrake itself remain, but user-specified associations disappear after a while.
Comment 2 Richard 2004-11-08 22:32:08 UTC
I believe I've found a workaround for this bug in Mandrake 10.

When you associate "acroread" with PDFs (for example) the following file is created:

$HOME/.kde/share/applnk-mdk/.hidden/acroread.desktop

While this file exists, so does the association; after a while, however, it disappears, UNLESS you do

chown 0:0 $HOME/.kde/share/applnk-mdk/.hidden/acroread.desktop
chmod 644 $HOME/.kde/share/applnk-mdk/.hidden/acroread.desktop

as root after the file has been created. I did this two or three weeks ago, and the association has stuck since then - a record!

Looks very much like a bug in Mandrake to me...
Comment 3 Greg 2004-11-09 09:37:22 UTC
Hi Richard,

Thanks for that. Just one question: 
Are you saying operate an a user's $HOME, as root OR root's $HOME, as root?
I ask this because, on my machine, the content of 
$HOME/.kde/share/applnk-mdk/.hidden/ for root, is empty but for a user, 
contains all sorts of <app>.desktop files.

Cheers,


Greg


I know I said 'one' question but...
Any idea why this happens? Or any response from Mandrake? 



On Monday 08 Nov 2004 21:32, Richard wrote:
> ------- You are receiving this mail because: -------
> You are a voter for the bug, or are watching someone who is.
>
> http://bugs.kde.org/show_bug.cgi?id=70533
>
>
>
>
> ------- Additional Comments From rjdymond gmail com  2004-11-08 22:32
> ------- I believe I've found a workaround for this bug in Mandrake 10.
>
> When you associate "acroread" with PDFs (for example) the following file is
> created:
>
> $HOME/.kde/share/applnk-mdk/.hidden/acroread.desktop
>
> While this file exists, so does the association; after a while, however, it
> disappears, UNLESS you do
>
> chown 0:0 $HOME/.kde/share/applnk-mdk/.hidden/acroread.desktop
> chmod 644 $HOME/.kde/share/applnk-mdk/.hidden/acroread.desktop
>
> as root after the file has been created. I did this two or three weeks ago,
> and the association has stuck since then - a record!
>
> Looks very much like a bug in Mandrake to me...

Comment 4 Richard 2004-11-09 16:20:21 UTC
Oops, sorry for the confusion there! I mean operate on the normal user's $HOME, not root's home. So replace $HOME with /home/<username> (or ~username) in the commands I gave:

su (enter root password)
chown 0:0 ~username/.kde/share/applnk-mdk/.hidden/acroread.desktop
chmod 644 ~username/.kde/share/applnk-mdk/.hidden/acroread.desktop

My guess was that some process owned by the user was removing the .desktop files, so had the idea of making them readable but unremovable by that user. A hack, but it seems to work. I've no idea what that process might be, nor have I contacted Mandrake about it...
Comment 5 Richard 2004-11-11 12:03:28 UTC
Looks as if Mandrake's aware of this problem at least:

http://qa.mandrakesoft.com/show_bug.cgi?id=8673
Comment 6 Greg 2004-11-11 23:28:42 UTC
I tried the chown chmod solution but it didn't stick!

I noticed various similarly constructed folders around with variations on the <app>.desktop collection. Can someone explain why there are so many.

Anyone in Mandrake able to give an approximate date when this might get looked at or (dare I say it?), fixed? I'd offer myself but I do usability, not coding :o)

Cheers,

Greg
Comment 7 Richard 2004-11-12 10:51:00 UTC
Hmm...my user-specified associations are still there, but it looks as if it's just by a fluke. :( According to the Mandrake bugzilla entry, the associations are wiped whenever you install a package that requires a menu update. I've done a couple of updates via urpmi recently, but presumably nothing that kicked off update-menus.
Comment 8 Greg 2004-11-12 19:50:07 UTC
I've just copied the $HOME/.kde/share/applnk-mdk/.hidden/ directory as $HOME/.kde/share/applnk-mdk/.firsthidden/ and I've created a script to copy .hidden as .lasthidden and then .firsthidden as .hidden, thus keeping a copy(.lasthidden) of the broken directory(.hidden)  then replacing it with a copy that has the correct file associations (.firsthidden). Obviously this is a painful solution if you start creating new file associations. I guess I'll have to create a script that does the reverse and snapshots .hidden over .firsthidden

Hope you followed all that?

Cheers,

Greg
Comment 9 Martin Koller 2005-01-09 14:23:49 UTC
As this is a Mandrake specific problem, I'll close it here.
Comment 10 Nicolas Goutte 2005-05-20 17:03:28 UTC
*** Bug 60566 has been marked as a duplicate of this bug. ***