After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 138033 - MIME misdetection makes file unopenable
MIME misdetection makes file unopenable
Product: nautilus
Classification: Core
Component: File and Folder Operations
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 138681 139629 152079 154074 318326 329688 341618 352655 (view as bug list)
Depends on:
Reported: 2004-03-25 02:24 UTC by Dan Winship
Modified: 2010-04-11 00:09 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10

Description Dan Winship 2004-03-25 02:24:07 UTC
Start 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.
Comment 1 Kjartan Maraas 2004-03-28 18:27:39 UTC
I think this is fixed in a later shared-mime-info release. Please upgrade and
report back.
Comment 2 Tommi Komulainen 2004-05-06 18:53:36 UTC
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.
Comment 3 Christophe Fergeau 2004-05-14 19:28:13 UTC
You probably aren't using freedesktop shared mime info 0.14 or newer.
Comment 4 Dan Winship 2004-05-14 20:31:05 UTC
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
Comment 5 Eric Butler 2004-05-22 07:43:23 UTC
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.
Comment 6 Stanislav Brabec 2004-10-07 23:04:14 UTC
See also bug 138033.
Comment 7 Stanislav Brabec 2004-10-08 13:47:17 UTC
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 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:

These bugs does not cover gnome-mime-data x conflict, which were
not yet evaluated.
Comment 8 Matthew Gatto 2004-10-20 14:11:04 UTC
*** Bug 138681 has been marked as a duplicate of this bug. ***
Comment 9 Matthew Gatto 2004-10-20 14:12:25 UTC
*** Bug 152079 has been marked as a duplicate of this bug. ***
Comment 10 Matthew Gatto 2004-10-20 14:15:46 UTC
patch for creating an 'Open Anyway' button in the dialog is in bug 154074
Comment 11 Matthew Gatto 2004-10-20 14:16:26 UTC
*** Bug 154074 has been marked as a duplicate of this bug. ***
Comment 12 Stanislav Brabec 2004-10-28 01:11:37 UTC
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.


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
Comment 13 Dan Winship 2004-10-28 14:09:00 UTC
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.
Comment 14 Stanislav Brabec 2004-10-28 18:27:33 UTC
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

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.
Comment 15 Matthew Gatto 2004-10-29 01:14:21 UTC
*** Bug 139629 has been marked as a duplicate of this bug. ***
Comment 16 Stanislav Brabec 2005-03-10 21:15:45 UTC
Proposal for partial solution in shared-mime-info:
Comment 17 Stanislav Brabec 2005-03-21 13:11:23 UTC
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.
Comment 18 Stanislav Brabec 2005-04-14 11:28:35 UTC
Related: bug 171595 (can fix XML and TIFF based formats, like XHTML, SVG, dcraw).
Comment 19 Christian Kirbach 2005-10-09 21:07:10 UTC
*** Bug 318326 has been marked as a duplicate of this bug. ***
Comment 20 Gregory S. Hayes 2005-10-27 00:34:20 UTC
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.
Comment 21 Fabio Bonelli 2006-02-03 09:57:01 UTC
*** Bug 329688 has been marked as a duplicate of this bug. ***
Comment 22 Sebastien Bacher 2006-05-13 12:49:26 UTC
*** Bug 341618 has been marked as a duplicate of this bug. ***
Comment 23 Lucas Rocha 2006-09-01 00:36:34 UTC
*** Bug 352655 has been marked as a duplicate of this bug. ***
Comment 24 Marius Andreiana 2007-07-27 11:07:15 UTC
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?

Comment 25 Stanislav Brabec 2007-07-27 14:03:51 UTC
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.
Comment 26 A. Walton 2010-04-11 00:09:11 UTC
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.