Created attachment 185 [details] [review]
Patch against shared-mime-info.
I think there is a bug in this entry. Why does it say little32 and not little16?
Data in little-endian is: 0xcfd0e011
In the magic file this gets converted by update-mime-database to: 11 e0 d0 cf
But the .ppt files start with d0 cf 11 e0 (says od -ctx1 foo.ppt).
So the word size is 2, not 4, isn't it?
Sorry, I said nonsense. Here's a better analysis, comparing with the tnef magic:
The magic for application/ms-tnef is:
<match type="little32" value="0x223e9f78" offset="0"/>
In the generated magic file it becomes:
78 9f 3e 22
which is the actual expected value in the file. The spec says this is "in big endian order", but I think this is true only when a word size is specified. Otherwise the data in the generated magic file is simply the expected data in host order. No problem there, except that the spec could be clarified.
Now for powerpoint, the entry is <match type="little32" value="0xcfd0e011" offset="0"/>. According to the above, shouldn't this be 0xe011cfd0 instead? Then it would generate d0 cf 11 e0 as one would expect. I realize now that "little32" means update-mime-database applies the endianness-conversion, the implementations don't have to do any swapping (no word-size set, which is good).
Created attachment 10302 [details] [review]
The fix as described in my last comment, please apply.
Committed, thanks. Closing.
Ouch, I found out now that actually this magic should be removed altogether.
It is not specific to powerpoint files, it's generic x-ole-storage magic.
I opened the first .doc file I found on my harddisk and it started with d0 cf 11 e0! So it is autodetected as powerpoint (as caught by kde's kmimetype unit tests -- aren't there unit tests for shared-mime-info?)
See the magic in x-ole-storage:
<match type="string" value="\320\317\021\340\241\261\032\341" offset="0"/>
The first four bytes are actually 0xe011cfd0 exactly. This magic definitely doesn't belong to powerpoint. Please apply this patch:
--- freedesktop.org.xml.in 20 Nov 2007 14:37:39 -0000 1.287
+++ freedesktop.org.xml.in 26 Nov 2007 13:09:31 -0000
@@ -381,9 +381,6 @@ command to generate the output files.
- <magic priority="50">
- <match type="little32" value="0xe011cfd0" offset="0"/>
Short question: Is this report still open for searching magic pattern of Powerpoint files? Or can this report be closed?
The current version in CVS does not contain the magic pattern of x-ole-storage for Powerpoint files anymore.
I believe this is fixed already.