KDE always associates *.jar with the zip mime type

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.

$ 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.

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

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.

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

could you add a file example to the bug?

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

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?

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)

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.

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.

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.

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 :)

I confirm this bug in Kubuntu 9.10.

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

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

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

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.

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