GNOME Bugzilla – Bug 138033
MIME misdetection makes file unopenable
Last modified: 2010-04-11 00:09:11 UTC
Start OpenOffice.org. Create a new spreadsheet, type something in it, and save it as an xls file. Now try to open it in nautilus. Nautilus will complain that it's actually a doc file masquerading as an xls file, and refuse to open it. The fact that it misdetects it is a gnome-vfs bug, but nautilus's behavior here is really annoying. And there doesn't seem to be any way to tell nautilus that the file is actually ok (other than renaming it to ".doc", which happens to work in this case because the handler for .doc files is also OOo). Every time I try to open the file, nautilus complains again, and I have to use right click -> "Open with" again.
I think this is fixed in a later shared-mime-info release. Please upgrade and report back.
If both mime types have the same application as the handler, shouldn't nautilus ignore the mismatch? IMHO showing an error dialog in such a case isn't really helping the user.
You probably aren't using freedesktop shared mime info 0.14 or newer.
The fact that the file was misidentified is minor and easily fixed. But there will be other bugs in the mime db in the future, and nautilus needs to recognize that and not thwart the user in that case
Nautilus reads a "filetype" of "Samba Share" but sees it's actually a "Folder" for shares when using the network browser, which has the effect of rendering it 100% useless. An "open anyway" button would be a good temporary solution for this problem, but I would really like the ability to disable file extention/mimetype-xml-ish-file checking alltogether and just use libmagic.
See also bug 138033.
Sorry. Should be: See also bug 154074. Problem of current version of Nautilus is, that we have gnome mime-info *.mime (which supports suffix and suffix regexp match and priority) and shared-mime-info *.xml (which supports suffix match and magic and priority). There are more reasons for such conflicts: - upper mentioned MIME type databases are out of sync - non-standard MIME types are used (see http://www.iana.org/assignments/media-types/ for official registry) - files conform to more types (e. g. XHTML conforms XML and HTML) and there is no logic for proper assignment (file can have primary and secondary MIME type and it does not mean conflict) - gnome mime-info feature lack prevents correct detection (e. g. *.rpm can be binary package on Real Media data). Related bugs: http://freedesktop.org/bugzilla/show_bug.cgi?id=1304 http://bugzilla.ximian.com/show_bug.cgi?id=65517 http://bugzilla.gnome.org/show_bug.cgi?id=151845 http://bugzilla.gnome.org/show_bug.cgi?id=152159 http://freedesktop.org/bugzilla/show_bug.cgi?id=1321 http://freedesktop.org/bugzilla/show_bug.cgi?id=1427 These bugs does not cover gnome-mime-data x freedesktop.org conflict, which were not yet evaluated.
*** Bug 138681 has been marked as a duplicate of this bug. ***
*** Bug 152079 has been marked as a duplicate of this bug. ***
patch for creating an 'Open Anyway' button in the dialog is in bug 154074 (http://bugzilla.gnome.org/attachment.cgi?id=32075&action=view).
*** Bug 154074 has been marked as a duplicate of this bug. ***
Note that the patch is not optimal. Example: Raw photo file *.nef is based on TIFF standard and has image structure. It should be opened by GIMP (as Camera RAW file, using gnome-dcraw binding. But "Open" will use "TIFF image" and opens EOG. This should be simple to implement two buttons for two MIME types. But: 1) MIME database is full of bugs. In this case both buttons can have identical text, but different MIME types (e. g. MP3). 2) Nautilus is not yet familiar with MIME types and subtypes, as defined in RFC 2045 and RFC 2046. For more see my comment in http://freedesktop.org/bugzilla/show_bug.cgi?id=1608
Well, TIFF files suck that way. Another case came up in the discussion around merging gpdf and ggv; some scanner programs produce multi-page TIFF files as output rather than scanning to pdf, and those TIFFs should be viewed in a ggv/gpdf-like (paged) viewer rather than an eog-like (collection) viewer. But you can't tell that without looking into the TIFF structure. (EOG currently only lets you display the first page, because that's all that gdk-pixbuf supports, because no other image file type has the concept of multiple pages.) We won't be able to do the right thing with all TIFF files unless we have special TIFF-handling logic in the MIME spec/impl.
If such multi-part image has .tif suffix, the situation will be more complicated. But in case of .nef files, the problem is elsewhere: Suffix detection (which should be used as first) correctly detects, that dsc_1627.nef is image/x-dcraw. But then nautilus does file contents analysis, and it says, that it is image/tiff, which is basically correct, but image/x-dcraw is "contents" mime type and image/tiff is "data container" mime type: 1) In respect to RFC 2045 and RFC 2046, TIFF as a container should have data type application/tiff or multipart/tiff, but for historical reasons it has image/tiff. 2) It can be worked around using "alias" or "sub-class-of" in shared-mime-info definition of image/x-dcraw. But nautilus has not yet support for this concept. So it does not help, that I will define image/x-dcraw as sub-class-of image/tiff. 3) Even if TIFF MIME type will be multipart/tiff, nautilus do not know about special meaning on application/ and multipart/ MIME types (RFC 2045 and RFC 2046) and will complain anyway. The correct solution: 1) Simple: Use file contents detection only if file suffix detection fails or gives ambiguous results. Remove this warning at all. 2) Complete: Nautilus should know, that application/ and multipart/ can be "container" MIME types, and have contents of different MIME type, and implement "alias" and "sub-class-of". Then fix shared-mime-info and define these keywords, where appropriate.
*** Bug 139629 has been marked as a duplicate of this bug. ***
Proposal for partial solution in shared-mime-info: http://bugs.freedesktop.org/show_bug.cgi?id=2692
GNOME 2.10 nautilus has subtype support, but it depends on CVS version of shared-mime-info. It can solve many upper mentioned conflicts and also bug 168283.
Related: bug 171595 (can fix XML and TIFF based formats, like XHTML, SVG, dcraw).
*** Bug 318326 has been marked as a duplicate of this bug. ***
Would it be possible to have a button to correct the issue (i.e. rename the file) or a prefrence item to disable the warning. This seems to crop up a lot, like opening .nfo, .wmv, etc. files.
*** Bug 329688 has been marked as a duplicate of this bug. ***
*** Bug 341618 has been marked as a duplicate of this bug. ***
*** Bug 352655 has been marked as a duplicate of this bug. ***
More than 3 years after this has been reported and still not fixed... Now I cannot open .html files because they are detected as .xml What's the security benefit of this dialog, if any? Preventing gimp from opening an .sh file renamed to .png? Could this 'feature' simply be removed? Please consider users opinion too - how many reports and dupes do they have to report? http://www.google.ro/search?q=%22Cannot+open%22+%22indicates+that+this+file+is+of+type%22&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
See bug 154074 comment 1 for a patch to add "Open anyway". It is for an old version of GNOME, but if there will be any interest, it is possible to port it.
No updates in years and a complete rewrite of the mime detection code means that this bug is most likely obsolete. Please reopen if this is not the case. Thanks.