Bug 435 - Proposed .ppt/.pot changes
Summary: Proposed .ppt/.pot changes
Alias: None
Product: shared-mime-info
Classification: Unclassified
Component: freedesktop.org.xml (show other bugs)
Version: unspecified
Hardware: All All
: medium normal
Assignee: Jonathan Blandford
QA Contact:
URL: http://freedesktop.org/pipermail/xdg/...
Depends on:
Reported: 2004-04-09 01:40 UTC by Christian - Manny Calavera - Neumair
Modified: 2008-02-05 10:49 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

Patch against shared-mime-info. (1.00 KB, patch)
2004-04-09 01:41 UTC, Christian - Manny Calavera - Neumair
Details | Splinter Review
The fix as described in my last comment, please apply. (501 bytes, patch)
2007-06-13 14:46 UTC, David Faure
Details | Splinter Review

Description Christian - Manny Calavera - Neumair 2004-04-09 01:40:25 UTC
See URL.

Comment 1 Christian - Manny Calavera - Neumair 2004-04-09 01:41:08 UTC
Created attachment 185 [details] [review]
Patch against shared-mime-info.
Comment 2 Christian - Manny Calavera - Neumair 2004-04-11 11:32:15 UTC
Committed. Closing.

Comment 3 David Faure 2007-03-15 12:14:36 UTC
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?
Comment 4 David Faure 2007-03-15 15:55:25 UTC
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).
Comment 5 David Faure 2007-06-13 14:46:44 UTC
Created attachment 10302 [details] [review]
The fix as described in my last comment, please apply.
Comment 6 Christian - Manny Calavera - Neumair 2007-06-13 15:06:06 UTC
Committed, thanks. Closing.
Comment 7 David Faure 2007-11-26 05:31:05 UTC
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.
     <glob pattern="*.ppt"/>
     <glob pattern="*.pps"/>
     <glob pattern="*.pot"/>
-    <magic priority="50">
-      <match type="little32" value="0xe011cfd0" offset="0"/>
-    </magic>
     <alias type="application/powerpoint"/>
     <alias type="application/mspowerpoint"/>
     <alias type="application/x-mspowerpoint"/>

Comment 8 Daniel Leidert 2008-02-05 10:46:58 UTC
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.
Comment 9 Bastien Nocera 2008-02-05 10:49:21 UTC
I believe this is fixed already.

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.