Version: 1.6.2 (using KDE 3.2.2, (3.0)) Compiler: gcc version 2.95.4 20011002 (Debian prerelease) OS: Linux (i686) release 2.2.20 There are several unconfirmed reports relating to something similar, but I cannot get application/octect stream attachments to remember to open with oowriter, even though I click on remember this association. This happens in several other cases.. This does not work.. Content-Type: application/msword; name="JonathanBai1.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="JonathanBai1.doc" When remember application is clicked, the following files were modified. ./config/kdeglobals ./config/kmailrc ./config/korgacrc ./mimelnk/application ./mimelnk/application/msword.desktop ./applnk/OpenOffice.org1.1 ./applnk/OpenOffice.org1.1/writer.desktop None of these seem to involve associations Same problem with PDF's Content-Type: application/pdf Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=MattJarvieResume.pdf This only changes ./share/config/kpdfrc ./share/mimelnk/application/pdf.desktop During the system update.. It remembers it WHILE I have the message selected, however moving to another message and back, and it has lost it's association already.
The only thing I get as an error is: kmail: WARNING: KMMessagePart::bodyDecoded(): body is binary but used as text!
A strace shows that it does access .kde/share/config/profilerc, which does hold the associations, however, but it doesn't access .local/share/applications/kde-kpdf.desktop correctly, I believe.. kde-pdf looks correct. [Desktop Entry] Categories=Qt;KDE;Graphics;PDFViewer DocPath=kpdf/kpdf.html Encoding=UTF-8 Exec=kpdf %i %m -caption "%c" GenericName=PDF Viewer Icon=kpdf InitialPreference=4 MimeType=application/pdf Name=KPDF Terminal=false Type=Application
On Monday 01 November 2004 19:24, michael@linuxmagic.com wrote: > There are several unconfirmed reports relating to something similar, but I cannot get application/octect stream attachments to remember to open with oowriter application/octet-stream is the default mimetype, the one meaning "no idea what this contains". You probably don't want to associate those with oowriter - otherwise any unknown piece of data would try to launch it. This might also trigger some "unknown mimetype" code in KDE which could be the reason for this association to fail. Not sure, better look at real mimetypes first. > None of these seem to involve associations Really? No MimeType or ServiceTypes line in applnk/OpenOffice.org1.1/writer.desktop > This only changes > ./share/config/kpdfrc > ./share/mimelnk/application/pdf.desktop > During the system update.. And profilerc, and .local/share/applications/kde-kpdf.desktop as you found out. profilerc is only about the *ordering* of the applications. The real question is if kde-kpdf contains the association to application/pdf, and apparently it does. So I don't see how it couldn't work :-/ Must be a problem with ksycoca, if the .desktop files are fine. In a terminal, if you type "kbuildsycoca", does it error out? [If you see warnings about unrelated unknown mimetypes, ignore those, they are fine]. If you click on a .pdf in konqueror, does it open in the right application?
First, no, kbuildsycoca does not error out..(other than the GUI warning, and says reusing existing ksycoca) Konqueror doesn't SEEM to exhibit the same problem. applnk/OpenOffice.org1.1/writer.desktop is as follows [Desktop Entry] Comment=OpenOffice.org Text Document Encoding=UTF-8 Exec=/usr/bin/oowriter %U Icon=ooo_writer.xpm InitialPreference=2 MimeType=application/vnd.sun.xml.writer;application/vnd.sun.xml.writer.template;application/vnd.sun.xml.writer.global;application/vnd.stardivision.writer;application/msword;application/vnd.ms-word;application/x-doc;text/rtf MultipleArgs=false Name=OpenOffice.org Writer Terminal=false Type=Application Version=0.92 So, yeah it should work, but it doesn't and that's why I filed a bug report.. :)
*** This bug has been marked as a duplicate of 81561 ***