The magic for application/x-java-keystore says <match type="host32" value="0xfeedfeed" offset="0"/>
And the test file test.jks starts with 0xFE, 0xED, 0xFE, 0xED. On a little-endian machine this leads to a value of 0xedfeedfe when read as a single 32-bit value. So this does not match. Am I missing something? I found this with an implementation which does not go through mime.cache but reads directly from the XML, so the fact that xdgmime works on this file might indicate a bug related to the mime.cache intermediary? http://mindprod.com/jgloss/cacerts.html says "The first four signature bytes of a Sun cacerts file in hex are FEEDFEED." so I wonder if this rule should say big32 instead of host32. With big32, both the s-m-i testsuite and my implementation (which uses the same testsuite) pass. Everything else passes, which makes me wonder if this is the only "host" match actually used by the test suite ;) Actually, if it's not, then I have to assume the test suite is known broken on big-endian machines, given that any "host" match would fail there, unless we put two versions of the file in the testsuite (one generated for little-endian machines and one generated for big-endian machines). But apparently this isn't needed yet, if I'm right that the java keystore magic should say big32. -- David Faure, [email protected], http://www.davidfaure.fr Working on KDE Frameworks 5 _______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
