KDE always associates *.jar with the zip mime type

[Andrew]

Binary package hint: krusader

Krusader, dolphin and other KDE applications incorrectly map the application/x-jar mime type. Gnome and XFCE and other non-KDE applications correctly interpret *.jar as application/x-jar, but not KDE.

I have followed all of the KDE instructions including:
http://www.krusader.org/handbook/faq_usage.html#faqu_jar
http://www.krusader.org/phpBB/viewtopic.php?p=9166

And have scoured my mimelnk and other *.desktop files and have verified that *.jar is only associated with Java and never zip. KDE incorrectly treats *.jar as application/zip anyways.

I have verified that krusader has no jar or java-archive or any thing else in the karc protocol and have verified that *.jar is mapped correctly under the KDE4 system settings application (file mapping).

KDE still stubbornly treats *.jar as a zip file. As a result I cannot launch java applications packaged as jar files without running it by hand.

I have exhausted google and all other resources, no one has replied to my launchpad question (https://answers.launchpad.net/ubuntu/+question/51806) in over a month and have come to the conclusion that it is probably a bug.

Versions:
xubuntu intrepid
krusader 2.0~svn6078-1ubuntu1
dolphin 4:4.1.3-0ubuntu1~intrepid1
systemsettings 4:4.1.3-0ubuntu1~intrepid1
kdebase-data 4:4.1.3-0ubuntu1~intrepid1

Sorry if it is not a bug, but I just cannot find any reason why KDE would map *.jar as a zip file.

[Jonathan Thomas (echidnaman)]

Hi,

All KDE applications since KDE4 use shared-mime-info to detect mimetype. It is quite possible that this is a bug in shared-mime-info. To be sure, though, could you run "xdg-mime query filetype thenameofyourfilegoeshere" in the terminal in the directory your jar file is in? Thanks.

[Andrew (andrew-rw-robinson)]

$ xdg-mime query filetype jdevstudio11111install.jar
application/x-java-archive

But Krusader still shows this as type "Zip Archive" in the file properties, which if I open the edit file type, using the button, it opens thde "Edit File Type application/zip - KEditFileType" dialog. Under that, "*.zip" is the only filename pattern.

This really appears to be a bug as even xdg-mime shows the correct mime type, but Krusader does not.

[Sebastien Bacher (seb128)]

that's not a shared-mime-info bug xdg-info or gvfs-info are correct there

[David Nemeskey (nemeskeyd)]

Actually for me, xdg-mime query filetype returns application/x-jar, which does not exist, instead of application/x-java-archive.

kmimetypefinder returns the following results:
$ kmimetypefinder -f JDownloader.jar
application/x-java-archive
(accuracy 20)
$ kmimetypefinder -c JDownloader.jar
application/zip
(accuracy 40)

I do not see how the score of the filename-based result can be so low. At least it returns x-java-archive. Actually, I have an idea: the mime database also contains an application/java-archive key, which associates jar files with the Sun Java Runtime.

I have completely reinstalled my system with 9.04. However, at first I installed Ubuntu (with Gnome), so maybe that also has to do something with it? It is not on my system anymore, though.

[David Nemeskey (nemeskeyd)]

I changed the status of shared-mime-info to New, because xdg-mime doesn't return the correct mime type either (see previous post).

[Sebastien Bacher (seb128)]

could you add a file example to the bug?

[flying sheep (flying-sheep)]

as far as i see every .jar is affected.
downloaded, created manually, by netbeans and with eclipse…

[Claudio (cwr)]

Same problem here since at least 8.10 - so I tried the same under OpenSuse based KDE 4.3 LiveCD - xdg-mime didn't give any output at all an kmimetypefinder gave the same results as David said but with the accuracy of 100 for -f - so in Dolphin the file is correctly associated with .jar.
Same results in Mandriva 2009 Spring and Fedora 11 but here the kmimetypefinder command doesn't accept -c or -f and just gives application/x-java-archive (accuracy 100).
On rigth click Properties all the three also show "Type: Java-Archive" und below the additional entry "Content: Zip archive".

Btw. - how is the accuracy of kmimetypefinder calculated?

[Harald Sitter (apachelogger)]

sun-java6-jre: /usr/share/mime/packages/sun-java6-jre.xml
this file is at fault.

Quoting:
 <mime-type type="application/java-archive">
  <comment>Java Archive</comment>
  <glob pattern="*.jar"/>
 </mime-type>

Since this overrides the default fdo xml it decreases the hit accuracy (thus we get 40 in kmimetypefinder...) only the file extension matches up, while everything else indicates zip, so result is zip, since a file extension can be wrong at times.

How to proof:
- remove above quoted parts from the affected file
- sudo update-mime-database /usr/share/mime
- kbuildsycoca4
- kmimetypefinder jNetTool-0.4.0.jar
application/x-java-archive
(accuracy 100)

[David Faure (faure)]

Reported in KDE as https://bugs.kde.org/show_bug.cgi?id=207517, but this is indeed a debian/ubuntu bug. There's no reason for /usr/share/mime/packages/sun-java6-jre.xml to exist, it only redefines what freedesktop.org.xml already defines, and with another mimetype name.
That file should be removed from the package.

The reason the accuracy is low is that there's a conflict on the *.jar glob, when both application/java-archive (from packages/sun-java5-jre.xml) and application/x-java-archive (from freedesktop.org.xml) are associated with it. So kmimetypefinder doesn't really know which one to choose. To help deciding that it does mimetype sniffing (looking at the contents), and that says application/zip - because the magic for jar files seems wrong/incomplete.

freedesktop.org.xml says
    <magic priority="85">
      <match value="PK\003\004" type="string" offset="0">
        <match value="0xcafe" type="host16" offset="40"/>
      </match>
    </magic>
but although I see PK\003\004 in all jar files (the zip header), I don't see 0xcafe at offset 40. Does someone know of a proper way to recognize a jar file from its contents?

Anyway all this seems to come from the missing application/java-archive alias for application/x-java-archive in freedesktop.org.xml (it should have been defined as an alias, not as a conflicting glob, in the xml file...). That mimetype name has NOT been registered to IANA, so in theory it should have a x- prefix, but well, it seems commonly used that way so I think I can add it to shared-mime-info.

[James Stansell (jamesstansell)]

I haven't looked at the jar spec lately, but it should be a safe assumption that all jar files have a META-INF folder. I don't think you can assume a fixed location for it though.

Also, this report seems to be focused on so-called 'executable' jar files, which have the distinction of defining a Main-Class property in the META-INF/MANIFEST.MF file.

For reference, here http://java.sun.com/docs/books/tutorial/deployment/jar/index.html is a general overview; I'm sure there's a more technical spec available too.

[James Stansell (jamesstansell)]

OK, the spec http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html says "A JAR file is essentially a zip file that contains an optional META-INF directory." So the META-INF directory may not always exist.

Also, I couldn't find any mention in the spec (or other docs from sun) of file magic for jar files.

I believe the 0xcafe magic match is really for java class files. Most interesting jar files (especially executable jars) will have at least one class file, but once again I don't think any particular location in the file can be assumed.

[David Faure (faure)]

And in addition, the .class files get compressed inside the .jar file, so their contents cannot be found at all ;-)

(The lack of a precise offset wouldn't be a big problem in itself, shared-mime-info has support for scanning a range of byte positions.)

Thanks for the info, wrong magic removed from shared-mime-info's freedesktop.org.xml

Now all we need is for /usr/share/mime/packages/sun-java6-jre.xml to be removed :)

[Chuck Ritola (cobra176)]

I confirm this bug in Kubuntu 9.10.

Workaround involving removing the xml files and then updating works for me.

[Taras Puchko (taras-puchko)]

Jar files do have 0xcafe at offset 40 displayed as "fe ca" at offset 0x28 in a hex viewer. Here is the link to the code that writes this JAR_MAGIC number: http://kickjava.com/src/java/util/jar/JarOutputStream.java.htm

[flying sheep (flying-sheep)]

would it be possible to fix the packaging? you just have to remove one file, that can’t be difficult.

[Jonathan Riddell (jr)]

This package is from the Canonical partner repository. It's a priorietary package so there may be limited changes possible. Subscribed brian-thomason who is incharge of it.

[flying sheep (flying-sheep)]

This is ridiculous. This bug is there for ages, and all that has to be done is to add a post-install hook that removes that file after it was installed from the 3-rd party repo, or a pre-install hook that removes it from the package.

I created a script that hopefully eases this process of repeating these steps every time java is upgraded to another version where this bug isn’t fixed. If I made a mistake in the script, please tell me so and I’ll fix it.

Link to script: https://gist.github.com/1250868