Version: 3.2.2 (using KDE 3.2.3, (testing/unstable)) Compiler: gcc version 3.3.3 (Debian 20040422) OS: Linux (i686) release 2.4.25-1-386 I've noticed this with the latest KDE packages from Debian testing (sarge) on both machines I run KDE on. Let's say I have some OGG files, which do not have a preset handler application. I'd like to associate these with xmms, so I right-click on an OGG file, select "Open with...", type xmms in the text field and then check the "Remember application association for this type of file" box. I then hit OK and the "Updating system configuration' box pops up. Once it's done, XMMS plays my file. If I quit XMMS and re-click on the same file (left-click this time), I get a prompt to choose an application once more! Closing the konqueror instance and opening another window doesn't work. Setting the association through kcontrol->KDE Components->File Associations similarly doesn't work. Right-clicking on an un-associated file, selecting "Properties" and then clicking on the small "Tool" icon next to the file type description (which btw correctly comes up as "Ogg Vorbis Audio) has absolutely no effect; it doesn't bring up the file associations window as used to happen with older versions of KDE 3.x. This behavior looks very similar to the one reported in http://bugs.kde.org/show_bug.cgi?id=70533 with the difference that in my case it is consistant - no new file associations are kept/honored by the system.
I am having the exact same issue on Fedora 2. I have noticed this bug posted by many different people on many different sites. I'm not sure why nobody has come up with a fix on any of these sites I've seen, it effectively makes KDE not so useful.
I have the same problem on Debian sid with 3.3.1 packages.
I'm not sure at all about it, but maybe this is a workaround (worked for me). - exit all kde apps - run "kcmshell filetypes" from terminal - change associations and save.
Nope. Not here. I can add new file associations, but it doesn't remember which program it should open it with, which is the real problem. I can add programs to the list of programs to open with, and save them. Everything seems to go fine, but when I open the file association editor again the list of programs is empty or the same as it was before I edited it. I can change all other settings except the list of programs to open with.
Just got the latest KDE 3.3.2 packages in Debian unstable. I still can't change file associations. This is a damn annoying bug.
Ok I finally investigated this with one of the kate developers. I found the following workaround: Simply type in the command line manually instead of using the tree to navigate to the application you want to use. Doing that fixes not only this issue for me, but also fixes the problems I posted in http://bugs.kde.org/show_bug.cgi?id=95973 and http://bugs.kde.org/show_bug.cgi?id=95975 because the file will not be downloaded locally if I type the command line manually. So can people please try this to see if it helps? Kind Regards Anders E. Andersen
I believe that if you installed KDE before this bug appeared, your installation will continue to work fine after this bug was introduced. Only new installations from after the bug was introduced are affected. So people who don't have this issue will continue to not be affected. In other words this needs to be tested on a brand new installation.
*** This bug has been confirmed by popular vote. ***
Same as http://bugs.kde.org/show_bug.cgi?id=60566 ?
The thing that has to be made clear, is that as far as this bug is concerned, program associations cannot be made at all. At least not by selecting the desired application from the application tree. If you try it, everything will seem to go fine. The dialog with the progress bar will appear as normal, and when it is gone, the desired program will be started. But when you check the same file again the program association is not there. It is NOT forgotten later as the other bug seems to suggest. Note also the workaround I suggested above. If you type in the appropriate command line manually and select save, then the program association is remembered, at least on my system. The icon in front of the application name is blank however, as if it can't find the program link or something.. I don't know why. I think if you can find out why the icon is blank, and doesn't show the program icon for the program you are using, then you are halfway to finding a solution for this problem. It would be a good start if other people who has commented here could check if the workaround works for them. Lastly I would just want to add, that there are a number of similar sounding bugs, if you search the database. They seem to be all marked as fixed however.
Could the people having these problems see if the directories in ~/.kde (or the corresponding directory defined by $KDEDIR) are writable? Also search in this $KDEDIR/share/mimelnk directory (and its subdirectories) a .desktop file created for the mime type. May be the problem is what is in this .desktop file. Have a nice day!
> Could the people having these problems see if the directories in > ~/.kde (or the corresponding directory defined by $KDEDIR) are writable? asus:~/.kde> ls -al totalt 20 drwx------ 5 andersa andersa 4096 2005-02-11 12:49 . drwxr-xr-x 35 andersa andersa 4096 2005-05-20 16:26 .. drwx------ 2 andersa andersa 4096 2004-12-09 00:51 Autostart lrwxr-xr-x 1 andersa andersa 25 2004-12-09 00:50 cache-asus -> /var/tmp/kdecache-andersa lrwxr-xr-x 1 andersa andersa 25 2004-12-14 21:46 cache-asus.ellenshoej.dk -> /var/tmp/kdecache-andersa drwxr-xr-x 2 andersa andersa 4096 2005-02-11 12:50 env drwx------ 9 andersa andersa 4096 2005-01-23 19:04 share lrwxr-xr-x 1 andersa andersa 20 2004-12-09 00:50 socket-asus -> /tmp/ksocket-andersa lrwxr-xr-x 1 andersa andersa 20 2004-12-14 21:46 socket-asus.ellenshoej.dk -> /tmp/ksocket-andersa lrwxr-xr-x 1 andersa andersa 16 2004-12-09 00:50 tmp-asus -> /tmp/kde-andersa lrwxr-xr-x 1 andersa andersa 16 2004-12-14 21:46 tmp-asus.ellenshoej.dk -> /tmp/kde-andersa All directories below has 700 permissions. > Also search in this $KDEDIR/share/mimelnk directory (and its > subdirectories) a .desktop file created for the mime type. May be the > problem is what is in this .desktop file. I think the problem is with the main files, not the user files. The files in mimelnk look fine to me. If you delete them and make some changes to file associations they just come back the same. Anders
On Friday 20 May 2005 18:35, andersa@ellenshoej.dk wrote: (...) > > All directories below has 700 permissions. > > > Also search in this $KDEDIR/share/mimelnk directory (and its > > subdirectories) a .desktop file created for the mime type. May be the > > problem is what is in this .desktop file. > > I think the problem is with the main files, not the user files. The files > in mimelnk look fine to me. If you delete them and make some changes to > file associations they just come back the same. The modifications are done in the user files. So if for example there is something silly written to them, KDE cannot read it the next time. (Or may be an important information is missed or so on.) Have a nice day! > > Anders
This is still occurring in KDE 3.4.1 in Gentoo, although bizarrely it only started occurring after I had to rescue my /home partition from a dying drive. I will investigate by removing various files that relate to the file associations.
I tried strace'ing "kcmshell filetypes" and removed all the files in the ~/.kde/share/config/ folder that it accessed, but when I started it up again and made some changes, those changes weren't held as before.
This issue appears to have gone away since I upgraded to 3.4.2, I can supply some specific files if this is necessary for anyone to figure this one out.
I've found this bug very frustrating, as sometimes it seems to be there and then sometimes it doesn't seem to be there. But I think I've figured out something about what's causing it. I'll ask others who are interested to see if they can duplicate this behavior. First, suppose I am working with a filetype to whose associations I've never made any kind of change before. Then I have no problem using konqueror's embedded association editor and the application tree to make a change. I did this on .rm files (application/vnd.rn-realmedia) by doing "touch ~/test.rm", right clicking on it in konqueror, and then opening it in kedit, which, again, you must choose from the application tree. When I do that, everything works just fine. But now try this. Do the same thing with .ram files, except this time type "kedit" in the box at the top of the association editor. When I do that, the (empty) file opens just fine in kedit, but the association is not saved. What's worse, sometimes, at least, doing that sort of thing will prevent me from EVER getting changes, even those made using the application tree, to stick. If that did work for you, then try doing exactly the same thing again, but on some other filetype, say .g3. I'm guessing it won't work then. Note: I've not had any problem doing the foregoing with a filetype that has no existing association with an application. The issue here seems to be one about how different such information is merged. It may be a matter of KDE having been switched partly from an older system to a newer one, as part of the freedesktop initiative, but I'm not sure. When changes to file associations are made using 'kcmshell filetypes', those changes are recorded in ~/.kde/share/config/profilerc, at least on my system. But changes made using konqueror aren't recorded there. They turn up, rather, in the .desktop files in ~/.local/share/applications/, IF one uses the application tree. On the other hand, if one types the command in manually, then it turns up in ~/.kde/share/applnk/.hidden/, but only if there isn't already a .desktop file for the relevant application there. If there is, nothing happens at all. That file doesn't get clobbered, apparently. To confirm, try setting, say, gedit as the default for .g3 files, typing it in, not using the tree, and then try setting it as default for .ac3 files the same way. The first works for me; the second doesn't.
*** Bug 70518 has been marked as a duplicate of this bug. ***
I just did a clean Debian/unstable installation on my new Asus A6 laptop. This bug doesn't appear. File associations work as they should.
Right, it's a bug that we fixed with 3.4, I think.
You think? :) To make sure, I just checked my old laptop where the problem was apparent. It seems to work there also. It's the old installation but upgraded to the same packages as my new laptop. (Debian/unstable)
Yes, I'm not sure if it was 3.4.0, 3.4.1 or 3.5.0 that first came with the fix. But I know it's been fixed.
Unstable is using 3.4.3 at this time.
Just a heads up, I'm running gentoo, compiled 3.4.3 and mine seems to have this bug. I'm trying to associate .exe's with wine, and tried to add the association, told it to save it.It ran the program, added wine below the openwith option, and clicking that does work, but dbleclicking on file to run through wine is a no go, also probs keeping the icon... may be partial ignorance on my behalf, but pretty sure covered all the bases...
Same bug over here on 3.5.1 on fc4. Kcontrol reports ASSERT: "m_pService" in kopenwith.cpp (784) ASSERT: "service" in kservicelistwidget.cpp (247)
I have same problem on KDE 3.5.7 SuSE 10.3. http://bugs.kde.org/show_bug.cgi?id=155725