Version: 4.2.2 (using KDE 4.2.2) OS: Linux Installed from: Debian testing/unstable Packages KDE's file icons and the default apps that a file opens with seems to be based on that file's extension, which is a faulty way to identify a file type. File extensions should NOT be a *nix requirement for opening a file in the proper application.
What is the actual issue?
If a file doesn't have a file extension it doesn't have the proper icon for its file type. If a file has the wrong extension, the wrong app will try to open that file based on its extension and not on its file type. The issue is that files shouldn't be handled based on their extension. Discussions like this are all over the place: http://www.linuxquestions.org/questions/linux-newbie-8/linux-file-extension-vs-dos-file-extension-44530/ and yet they don't really hold up to be true within KDE. If I have a file 'shopping.odt' and rename it 'shopping.mp3' then Amarok or another music app will try to open it. Seems to work fine if a file has _no_ extension but sometimes files are named with dots: shopping.2009.sh where '.sh' may refer to any number of things (such as someone's initials), not just a shell script. So I would think that we want to treat a file according to its actual file type (such as the way /usr/bin/file does) rather than according to some possibly-incorrect extension. This would also prevent a user from possibly clicking on a video.avi file which may not actually be a video and may somehow cause problems (buffer overflow, windows executable, who knows what).
KDE's mime type system is not based uniquely on extensions, but also on content. Altough, content-based recognizing of file types is not always doable quickly (ie by reading a very small part of the file), and many file types relies on the extension only as identifier. Some of the issues you describe would seem (as you just provided a very generic description of them) application-specific issues; others (like the .sh case) are sort of unfixable, as you cannot determine whether it is a shell file even by reading some heading of the file.
> are sort of unfixable, as you cannot determine whether it is a shell file That is understandable, as it is a spcial-case type of text file I suppose, and the icon is still text-on-paper (in KDE4 Oxygen at least). But a file could be music with a .sh in its file name and not have an extension. > KDE's mime type system is not based uniquely on extensions, > but also on content Maybe the weighting of how that icon and the default app could be adjusted? A file named music.mp3 gets the mp3 icon, where as without an extension it seems to be more accurate. > content-based recognizing of file types is not always doable quickly Just because its not always doable quickly doesn't mean that the quick cases should be ignored. I would like the icon to reflect a best-guess as to the file type and currently Dolphin and the rest of KDE seems to go by extension only in my tests; never have I had it show an icon that doesn't pair with the extension. No extension works better but as I have said, sometimes a file name includes a .abc in it without it necessarily being used as an extension.
@Pino: Should this report be moved to kdelibs as wish? I believe the currently used approach in KDE works fine and is a good compromise between performance and accuracy. Still if somebody wants to change this, it has to be done in kdelibs...
@Peter: please (in private) tell me where the actual mime resolution is being done.
The mime type resolution is done in kdelibs/kio/kio/kfileitem.* I've moved it as wish to kdelibs (I'm currently trying to cleanup all open Dolphin bug reports...).
Any changes in this bug? It is still an issue.
DUP of bug 177339. (177339 is older, and has a more specific initial description and reproduction.) *** This bug has been marked as a duplicate of bug 177339 ***