https://bugs.kde.org/show_bug.cgi?id=425154
--- Comment #2 from Adam Fontenot <adam.m.fontenot+...@gmail.com> --- I agree that it's probably not a bug that other mimetypes inherit application/octet-stream. There are really two problems: One issue is that this inheritance isn't surfaced to the user in any meaningful way - from the user's point of view it's as though every single mimetype had the program added. Actually, it is possible to remove programs from individual mimetypes. I think this blacklists them, but this is not obvious: people experiencing this bug are reporting it as a program being added to every mimetype! Since that's not really what's happening, this suggests the current presentation of this information is flawed. The other issue is that random programs can get added to the application/octet-stream mimetype without the user's explicit request for this to happen. I think sometimes the "remember application association" box is checked by default, and if I pipe garbage from /dev/urandom into a file and try to open it, KDE shows it as application/octet-stream. So maybe it can happen that way? Or maybe opening certain files in programs directly from Firefox will lead to the mimetype getting added. Some possible solutions: 1. In the file associations module all the types appear under a menu with the title "Known Types". Maybe an entirely different section could be added for types that are inherited, call it "Inherited Types"? Or if application/octet-stream is the *only* type that gets inherited according to the spec, add a section of the KCM explicitly for "programs that open all files". 2. When a user tries to remove an inherited file association, pop up a dialogue: "ApplicationX is currently associated with the application/octet-stream type, which means it will open every file type by default. Would you like to remove this application's association with every file type, or just this one?" [Every File Type] [Just this One] [Cancel] (This is similar to how Google Calendar lets you delete all instances of a repeating event by just trying to delete one of them.) Obviously the specifics would need to be adapted to whatever the UI / usability folks think is the most useful to the end user. 3. Track down the different ways in which a user (or program) might incorrectly add a file association with application/octet-stream, and try to prevent this from happening without it being obvious to the user. In particular, in KDE applications, setting a program to open *one specific file* that KDE doesn't recognize should not set that program to open every other type of file, including ones that KDE does recognize. Example case using Okteta: suppose I have some memory dumps with the extension .bin or something. I might have hundreds of these, so I set Okteta to open them with "remember application association" checked. What actually happens: Okteta gets set to open every kind of file. What I probably expected to happen: Okteta gets set to open every file with the extension .bin that *doesn't* have a known magic pattern. At the least it would be good to give a warning: "KDE doesn't recognize this file type. Do you want to set Okteta to open all file types?" I suspect if Firefox isn't at fault then something similar must be happening with LibreOffice. Maybe at some point I had what I thought was a CSV saved with a .dat file extension or something, but was actually garbage. I set it to open with LibreOffice, and oops! All of my files now open in LibreOffice. 4. Applications that are only associated with a mimetype because they're inherited should be prioritized *after* applications that are associated directly, and more distant inheritances should be deprioritized accordingly. I can say for sure that this doesn't always happen: if LibreOffice gets added to application/octet-stream, it takes over all my .py files, which is obviously undesirable. -- You are receiving this mail because: You are watching all bug changes.
