Bug 197346

Here using:

Qt: 4.5.1 (qt-copy  971295)
KDE: 4.2.92 (KDE 4.2.92 (KDE 4.3 >= 20090617))
kdelibs svn rev. 984425 / kdebase svn rev. 984427
on ArchLinux i686 - Kernel 2.6.29.4

I can reproduce the bug

Further tests:

- "keditfiletype audio/mp3" works properly
- "kcmshell4 filetypes" also shows this behaviour.

Modifying the apps for "audio/mpeg" works properly, but not for "audio/mp3"
Just note that "audio/mp3" is not a "real mimetype" but the extension for "audio/mpeg". (Also, when "audio/mpeg" is selected, the filename patterns show "mp3" and "mpga"; however if "audio/mp3" is selected, no filename patters are shown)

@David: Could this be related then to this mixup of real mimetypes and extensions ?

Oh, I'm guessing something:

When you have the complete dialog:
if you edit the "audio/mp3" mimetype, if you add an application , then this is saved, but then the kcmshellApp will save the associated applications for "audio/mpeg" (as this is order by name ascending), and as "audio/mpeg" doesn't have this new added assoc application, it will delete it. And therefore, when the kcmmodule is updated after save, the "audio/mp3" "mime" will reflect the state of "audio/mpeg".

That would explain the associated programs not being remembered in this weird case.

This bug still exists in 4.3.85 :-(

I don't even have a audio/mp3 mimetype. The mimetype for mp3 files is audio/mpeg.
audio/mp3 is an alias for audio/mpeg

Hmm. I'll have to look at what we do with aliases....

I have the same problem.
But it is strange that, for example, mp3.xml is present in ~/.local/share/mime/audio/ (created by KDE for each first launch of a new user) and does not exist in /usr/share/mime/audio/

I use Kde 4.3.4 on a Debian sqeeze with shared-mime-info 0.70-1 version

Then there is a packages file that defines audio/mp3 for you. KDE doesn't define it, it must come from somewhere else (wine, maybe, or some distro hack).

Please search for "audio/mp3" in every directory returned by the command "kde4-config --path xdgdata-mime --locate packages/" and tell me what you find.

E.g. grep mp3 ~/.local/share/mime/packages/*
but also any other directory returned by the command above.

Hi David, I am not Francesco, but I have that mp3.xml too, generated by gentoo's update-mime-database tool.

mschiff@bart ~ $ kde4-config --path xdgdata-mime --locate packages/
/home/mschiff/.local/share/mime/packages/
mschiff@bart ~ $ grep mp3 ~/.local/share/mime/packages/*
/home/mschiff/.local/share/mime/packages/application-x-nsv-vp3-mp3.xml:    <mime-type type="application/x-nsv-vp3-mp3">
/home/mschiff/.local/share/mime/packages/audio-mp3.xml:    <mime-type type="audio/mp3">
/home/mschiff/.local/share/mime/packages/audio-mp3.xml:        <glob pattern="*.mp3"/>
mschiff@bart ~ $

I have found the same result of Marc Schiffbauer, except of the record "<glob
pattern="*.mp3"/>

The problem comes from this file, then: /home/mschiff/.local/share/mime/packages/application-x-nsv-vp3-mp3.xml

From its name, I would say that it was created by a webbrowser plugin (also called "netscape plugins"). Can you confirm that this file says "<!--MimeType generated by nspluginscan-->"?

Ah! And in that case, I found the bug: pluginscan.cpp uses KMimeType::mimeType() without "ResolveAliases" so it thinks the mimetype doesn't exist, and defines it. Pino is right, we really have to change mimeType() so it resolves aliases by default.

Hi David,

bingo!:
cat /home/mschiff/.local/share/mime/packages/application-x-nsv-vp3-mp3.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--MimeType generated by nspluginscan--><mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
    <mime-type type="application/x-nsv-vp3-mp3">
        <comment>Nullsoft Streaming Video</comment>
    </mime-type>
</mime-info>

Great that you found the bug! Any chance to find a bugfix in 4.4.2 then?

Marc

SVN commit 1097954 by dfaure:

As discussed with Pino: make alias resolution the default in KMimeType::mimeType.
There is just no good reason not to, aliases can be used anywhere, especially with
shared-mime-info replacing mimetypes with aliases over time (e.g. image/ico).

This fixes at least two bugs:
1) a bug noticed by Pino: if you set the old name as filter in kfiledialog, when
   updating s-m-i it won't work anymore (because aliases are not resolved)
2) the bug that nspluginscan would define mimetypes because "unknown" when they are
   in fact aliases.
BUG: 197346
Fixed for: 4.4.2


 M  +1 -1      services/kmimetype.h  
 M  +8 -4      tests/kmimetypetest.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1097954