There is a bug in the magic for application/x-java (*.class files). They start with \xCA \xFE \xBA \xBE. The current magic is type="host16" value="0xcafe", which doesn't match the above on little-endian systems. It was a bug in an old version of the file(1) magic file, which said "short 0xcafe", and this was ported to the fdo mime spec. It has been fixed in more recent versions to say: "belong 0xcafebabe", which indeed matches what I see at the beginning of class files (\xCA \xFE \xBA \xBE). Please apply the attached patch.
Created attachment 9214 [details] [review] patch for application/x-java
Thanks for your bug report! Does this also affect JAR files?
(In reply to comment #2) > Thanks for your bug report! An independent way to confirm the report is in the Java Virtual Machine Specification, chapter 4, http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html: Multibyte data items are always stored in big-endian order, where the high bytes come first. ... ClassFile { u4 magic; ... The magic item supplies the magic number identifying the class file format; it has the value 0xCAFEBABE. So we should test for belong/0xcafebabe, as in the original reporter's patch. > Does this also affect JAR files? Yes-ish. The match rule for application/x-java-archive is looking for an 0xcafe at offset 40, but nothing in the Jar File Specification http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html requires it to be there; only says a jar file is a zip file that may contain an optional META-INF directory. However (undocumentedly), Sun's jar file creation code in java/util/jar/JarOutputStream.java (in $JRE/lib/src.zip) can be seen putting it there, as a zip-header "extra field" with ID 0xcafe and length 0. That format is specified in pkware's APPNOTE.TXT, section J, to always use *little*-endian order, so this rule in application/x-java-archive should be leshort/0xcafe.
(In reply to comment #3) > So we should test for belong/0xcafebabe, as in the original reporter's patch. > > Does this also affect JAR files? > ... > should be leshort/0xcafe. s/belong/big32/ s/leshort/little16/ sorry, typing too fast. :)
(In reply to comment #3) > ... nothing in the Jar File Specification > http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html > requires it to be there; only says a jar file is a zip file that may > contain an optional META-INF directory. ^^^^^^^^^^^^^ So it follows by the way that application/x-java-archive should have a sub-class-of type="application/zip" element.
(In reply to comment #3) > Yes-ish. The match rule for application/x-java-archive is looking for > an 0xcafe at offset 40, Actually, the way I count, the offset should be 39, not 40. (In a test jar file I just made, it's at 39, match at 40 fails.) From http://www.pkware.com/documents/casestudies/APPNOTE.TXT A. Local file header: local file header signature 4 bytes (0x04034b50) version needed to extract 2 bytes general purpose bit flag 2 bytes compression method 2 bytes last mod file time 2 bytes last mod file date 2 bytes crc-32 4 bytes compressed size 4 bytes uncompressed size 4 bytes file name length 2 bytes extra field length 2 bytes file name (variable size) extra field (variable size) Sun's JAR writer always prepends the 0xcafe to the extra field, so it will be the first thing following the file name, but the file name is variable length. We can't do this check reliably without the capability of reading the file name length field and computing an offset from it. Otherwise, we have to assume what the first entry name will be, and it's usually META-INF/ (though the Jar File Specification nowhere requires that). In that case, we have the offset 4+2+2+2+2+2+4+4+4+2+2+length(META-INF/) = 39. As long as we are more or less assuming (reasonably) that META-INF/ will be the first entry, we might as well look for type='string' offset='26' value='\x9\0??META-INF/\xfe\xca' mask='0xffff0000ffffffffffffffffffffff'
Thanks Chapman for muddying this originally simple issue, now I'm still waiting for my patch to be applied :-) Jonathan, can you apply my patch please, and can we sort out JAR files later when the need arises and/or one of us three has time to write an actual patch for it?
2008-04-10 Bastien Nocera <hadess@hadess.net> * Makefile.am: error out when one of the tests fails * freedesktop.org.xml.in: Fix matchlet for application/x-java, patch by David Faure <faure@kde.org> (Closes: #10334) * tests/helloworld.java (helloworld), (helloworld.main): * tests/list: * tests/test.class: Add test case for Class and Java source files
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.