| Summary: | why does application/octet-stream have magic | ||
|---|---|---|---|
| Product: | shared-mime-info | Reporter: | Matthias Clasen <mclasen> |
| Component: | freedesktop.org.xml | Assignee: | Jonathan Blandford <jrb> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | high | CC: | bugzilla, faure |
| Version: | unspecified | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Matthias Clasen
2005-10-21 12:56:51 UTC
That was added in the very first version of freedesktop.org.xml.in, no idea what it's trying to match either... I see where this comes from. The original "magic" file from file(1) says: 0 short 0x1f1f old packed data # XXX - why *two* entries for "compacted data", one of which is # byte-order independent, and one of which is byte-order dependent? # 0 short 0x1fff compacted data # This string is valid for SunOS (BE) and a matching "short" is listed # in the Ultrix (LE) magic file. 0 string \377\037 compacted data 0 short 0145405 huf output And when this was converted to use mimetypes, for use in KDE-1, the descriptions were replaced with mimetypes, and for those there was no mimetype, so application/octet-stream was used. And then the magic file from KDE was used to generate parts of the shared-mimetype xml ;) Of course on hindsight having magic for octet-stream makes no sense, since it's the fallback in any case. I think the magic should just be removed, I see no usefulness in such generic magic (there could be any actual mimetype using compacted data internally). 2006-07-09 Bastien Nocera <hadess@hadess.net> * freedesktop.org.xml.in: remove the magic for application/octet-stream, it's silly (Closes: #4843) |
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.