nautilus's clever anti-hax0r detection is really dumb

Bug #19101 reported by Allison Karlitskaya
90
Affects Status Importance Assigned to Milestone
Nautilus
Expired
High
nautilus (Ubuntu)
Fix Released
Wishlist
Ubuntu Desktop Bugs

Bug Description

Cannot open attachment.cgi.html

The filename "attachment.cgi.html" indicates that this file is of type "HTML
page". The contents of the file indicate that the file is of type "differences
between files". If you open this file, the file might present a security risk to
your system.

Do not open the file unless you created the file yourself, or received the file
from a trusted source. To open the file, rename the file to the correct
extension for "differences between files", then open the file normally.
Alternatively, use the Open With menu to choose a specific application for the
file.

Can this error dialog please die now (or at least be special-cased to only apply
to situations where your computer is *actually* in danger)? It'd be great it
Nautilus just did the reasonable thing and opened the file in either ephy or
gedit. I can't really think of a case where opening a file like this could be a
security problem (except in the case where the file is explicitly marked
executable, and this could be handled as the special case). Certainly, in any
case where Nautilus is about to execute a script (rather than open it in an
editor) I'd like to be asked about it anyway.

For the record, Nautilus has the following preference:

Executable Text Files:
  ( ) Run executable text files when they are clicked.
  ( ) View executable text files when they are clicked.
  (o) Ask each time. <-- default.

Even if I set this to "Run executable text files when they are clicked" and
double click on a shellscript that has the extension ".sh" it opens in gedit
because it lacks mode +x.

http://bugzilla.gnome.org/show_bug.cgi?id=309862: http://bugzilla.gnome.org/show_bug.cgi?id=309862

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for your bug, it's already known upstream:
http://bugzilla.gnome.org/show_bug.cgi?id=309862, I've put your comment on it

Revision history for this message
Sebastien Bacher (seb128) wrote :

*** Bug 19191 has been marked as a duplicate of this bug. ***

Revision history for this message
Sebastien Bacher (seb128) wrote :

This upload fixes the issue:

 nautilus (2.11.91-0ubuntu1) breezy; urgency=low
 .
   * New upstream version:
     - Don't allow renaming of the desktop folder.
     - Make moves within burn:// possible.
     - Fixes to property browser drag and drop code.
     - Add Explorer-style keybindings.
     - Add timestamps to metafiles.
     - Make ESC switch back to the pathbar.
     - Use saner check for mime mismatching (Ubuntu: #12844).
     - Make progress dialog minimizable.
     - UI fixes.
     - Display the correct name for the trash folder (Ubuntu: #12955).
   * debian/control.in:
     - updated the Build-Depends for the new version and the changes.
   * debian/patches/01_lpi.patch:
     - launchpad integration patch.
   * debian/patches/02_autoconf.patch:
     - update configure.

Revision history for this message
Allison Karlitskaya (desrt) wrote :

Just now:

Cannot open attachment.cgi

The filename "attachment.cgi" indicates that this file is of type "CGI script".
The contents of the file indicate that the file is of type "differences between
files". If you open this file, the file might present a security risk to your
system.

Do not open the file unless you created the file yourself, or received the file
from a trusted source. To open the file, rename the file to the correct
extension for "differences between files", then open the file normally.
Alternatively, use the Open With menu to choose a specific application for the
file.

Revision history for this message
Sebastien Bacher (seb128) wrote :

your "difference between files" type is weird. I get the error but not this
type. Could you open a bug on bugzilla.gnome.org against nautilus for this?

Revision history for this message
Allison Karlitskaya (desrt) wrote :

"difference between files" is what the MIME DB calls a unified diff.

The specific file that causes this problem:
http://bugzilla.gnome.org/attachment.cgi?id=48557&action=view

If you click that link and go file->'save page as' in firefox you should get
offered "attachment.cgi" as a default filename (and in my case, Desktop as the
default location). If you then double click on the file you should get that
exact message.

Revision history for this message
Allison Karlitskaya (desrt) wrote :

Cannot open 4d03.mds

The filename "4d03.mds" indicates that this file is of type "MonoDevelop
solution". The contents of the file indicate that the file is of type "plain
text document". If you open this file, the file might present a security risk to
your system.

Do not open the file unless you created the file yourself, or received the file
from a trusted source. To open the file, rename the file to the correct
extension for "plain text document", then open the file normally. Alternatively,
use the Open With menu to choose a specific application for the file.

maybe ubuntu could vendor-patch this out?

Revision history for this message
Allison Karlitskaya (desrt) wrote :

FWIW, I just upgraded to breezy on the computer in the basement and one of the
first things that my sister noticed is that she can no longer open .wmv files.
(She gets an error about "extension says wmv but type says asf"). I don't know
if this is an actual regression or if she just noticed it now.... but that's a
fairly common enduser-type activity to have not work....

Revision history for this message
Simon Law (sfllaw) wrote :

I think your recent comments have more to do with bug 41772.

Does nautilus still warn spuriously for harmless files?

Changed in nautilus:
status: Unconfirmed → Needs Info
Revision history for this message
Allison Karlitskaya (desrt) wrote :

yes

Changed in nautilus:
status: Needs Info → Confirmed
Revision history for this message
Allison Karlitskaya (desrt) wrote :

this is definitely different from bug 41772 (but caused by a similar issue -- two different systems for detecting mime type).

this bug is much easier to fix and i'm astounded that it hasn't been fixed yet.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Ryan, the behaviour would be easy to change ... if upstream agreed to do that. I'm still not sure we should distro change that rather than argumenting with upstream until they change it for everybody ;)

Changed in nautilus:
status: Unconfirmed → Confirmed
Revision history for this message
Anita (a-lewis) wrote :

I've upgraded dapper to edgy and have been getting that message on .wav, .ogg, .png, .jpg, but not on .gif or .jpeg. Mine says it like this:

The filename "PNG_transparency_demonstration_1.png" indicates that this file is of type "png document". The contents of the file indicate that the file is of type "PNG image". If you open this file, the file might present a security risk to your system...

I note that it says it is type png document rather than png image.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Anita, could you run "grep "png document" ~/.local -r" and "grep "png document" /usr/share/mime -r" and copy to a comment any reference it founds about it?

Changed in nautilus:
assignee: seb128 → desktop-bugs
Revision history for this message
Anita (a-lewis) wrote : Re: [Bug 19101] Re: nautilus's clever anti-hax0r detection is really dumb

Sebastian, here is the result of the two commands:
=============================
$ grep "png document" ~/.local -r

/home/ajlewis2/.local/share/mime/packages/Override.xml:<mime-type
type="application/x-extension-jpg"><comment>jpg document</comment><glob
pattern="*.jpg"/></mime-type><mime-type
type="application/x-extension-png"><comment>png document</comment><glob
pattern="*.png"/></mime-type><mime-type
type="application/x-extension-ogg"><comment>ogg document</comment><glob
pattern="*.ogg"/></mime-type><mime-type
type="application/x-extension-wav"><comment>wav document</comment><glob
pattern="*.wav"/></mime-type></mime-info>
/home/ajlewis2/.local/share/mime/application/x-extension-png.xml:
<comment>png document</comment>
=================================
$ grep "png document" /usr/share/mime -r
$

No output on the second command.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Whatever has installed that /home/ajlewis2/.local/share/mime/packages/Override.xml and /home/ajlewis2/.local/share/mime/application/x-extension-png.xml is responsive for your issue, that's not due to nautilus or the distribution. Move those files away and your issue should be fixed

Revision history for this message
Anita (a-lewis) wrote :

I moved both files to my Desktop. I rebooted and the problem remains.
I also logged in as another user and did not have the problem opening a
.png. So, it is definitely something with my user.

I did look with dpkg -S to try to determine where the files came from.
They were not a part of any package. I imagine they must come from some
change made to the nautilus preferences. I do have kde installed as well
and have never used kde with the other user that is not having this problem.

Thanks,
Anita

Revision history for this message
Anita (a-lewis) wrote : Re: [Bug 19101] Re: [Bug 19101] Re: nautilus's clever anti-hax0r detection is really dumb

Ok, here is what I did that works.

cd ~/.local/share/
mv mime bu-mime

Try to open an existing .png and it fails
Right-click/properties/ and choose something other than Image Viewer.
It then opens. Repeat and set back to Image Viewer. It works.

The same works for .jpg and .ogg.

Download fresh .png. It opens without doing anything.

The question is: What is in ~/.local/share/mime that is causing the
problem. I assume that some of that stuff in there is useful and should
be there.

Thanks,
Anita

Revision history for this message
Anita (a-lewis) wrote :

Also changing the file's name will allow it to open:

Double-click linuxreality031.ogg. It fails with the message.
Rename it to linuxreality31.ogg - no change in the extension, just a new
name. Double-click and it opens.

Anita

Revision history for this message
Sebastien Bacher (seb128) wrote :

something probably written uncorrect changes to .locale/share/mime. Anyway that bug is not about that, better to take the discussion somewhere else to not flood the original submitter with messages about a different issue and make the bug confusing

Revision history for this message
Jan Niklas Hasse (jhasse) wrote :

I have the same bug when opening codeblocks projects: there file ending is cbp but Code::Blocks uses XML for its project files.

(sry i have only german message:)
"Der Dateiname »GetDotA.cbp« deutet darauf hin, dass der Typ dieser Datei »Code::Blocks Project« ist. Dem Dateiinhalt zu Folge handelt es sich jedoch um den Typen »XML-Dokument«"

This is critical!

Revision history for this message
Rthaduthd Anthnhkrc (nthnuekeu-deactivatedaccount) wrote :

*gah* ... I'm also having these problems. Non-geek family-members and friends do not understand what to do when this happens. :}

It happens a lot with mis-named videos downloaded with FrostWire. Right-clicking then selecting "open with" from the context-menu works of course - but it sucks big-time. There should be an option:

* "Always ignore and try playing/executing files ending with `.wmv' anyway."

..instead of just a cancel-button. :(

Revision history for this message
Steve K (steve10k) wrote :

Does anyone have a work-around handy, for disabling this entire "security" "feature"?

In my web searches, I find nothing about how to turn it off.
What I do see, are instances of the same error message
reported in numerous forums. The problem is normally
misinterpreted by the local geeks and gurus in these forums,
as an application level problem or (most commonly), a
missing filesystem permission on an executable file. The
real bug looks and sounds too much like deliberate sabotage
to seem possible.

I certainly don't need it, it's nothing but an annoyance to
anyone who pays attention to where the files on his or her
system came from. This "feature" adds nothing but extra time
and motion to the simplest and most frequently used task on
the desktop. I am seriously thinking about the time/effort
tradeoff in switching from Gnome to KDE on account of it.

Clueless newbies also don't need it, unless someone thinks
it's a good idea to protect them from hypothetical hostile
content by disabling the only file-open method they know
about. (Insert famous quote about unplugged computer
encased in a cube of concrete here.)

:o/

Steve

Revision history for this message
Caminomaster (caminomaster) wrote :

Because time is pasing and we still affected by that bug, I suggest you to make an update (or tell-us-how) to disable this feature until the bug is fixed, and launch it when it proved stable or better.

Please note that i'm not the only one suggesting to disable that feature. One of the thing that I really love of Ubuntu is the recognition of filetypes despite it's file extensions. That was pretty perfect until that bug appeared, and that comes against productivity (as a design workshop we interact with a lot of jpg's)
and is beginning to give us money losses. I'm so preoccupated.

I reiterate that maybe is better to disable it until fixed, or instead put a "always ignore for that filetype" buttom.
Thanks,
Caminomaster

Revision history for this message
Sebastien Bacher (seb128) wrote :

that dialog is not a bug, it happens only when the mimetype is not correct, do you have an example of problematic file to point?

Revision history for this message
Rthaduthd Anthnhkrc (nthnuekeu-deactivatedaccount) wrote : Re: [Bug 19101] Re: nautilus's clever anti-hax0r detection is really dumb

On 1/11/07, Sebastien Bacher <email address hidden> wrote:
> that dialog is not a bug, it happens only when the mimetype is not
> correct,

Which happens a lot and is handled in a very wrong and stupid way -
thus making it a bug.

>
> --
> nautilus's clever anti-hax0r detection is really dumb
> https://launchpad.net/bugs/19101
>

--
Mvh,
Lars Rune Nøstdal
http://nostdal.org/

Revision history for this message
Sebastien Bacher (seb128) wrote :

it doesn't happen that often and such comment are not really useful, if you want to get that bug fixed the best way would probable to talk with upstream about the proper way to fix it

Revision history for this message
Rthaduthd Anthnhkrc (nthnuekeu-deactivatedaccount) wrote :

On 1/11/07, Sebastien Bacher <email address hidden> wrote:
> it doesn't happen that often

lol.. And this is an argument, how?

It happens often enough, and when it happens it happens every time as
a "n00b" does not know how to fix it "permanently" -- he is stuck. For
example I have friends and family that are totally unable to handle
nor understand this. Try to imagine yourself in the situation - if you
have the ability.

*shrug*..in short; do not sink to a level of simple denial -- this
_is_ a bug one way or another.

> and such comment are not really useful

lol -- And yours is how exactly? Maybe it makes you "feel better"
imagining "it's not really a bug" -- or that it "does not happen often
enough to be a bug" ..... x_x .... stop feeling and start thinking.

> if you want to get that bug fixed the best way would probable to talk with
> upstream about the proper way to fix it

Yes, after having looked into this I believe the upstream is aware of
it - and has been for a long time.

--
Mvh,
Lars Rune Nøstdal
http://nostdal.org/

Revision history for this message
Steve K (steve10k) wrote :

--- Sebastien Bacher <email address hidden> wrote:

> it doesn't happen that often and such comment are not really
> useful, if you want to get that bug fixed the best way would
> probable to talk with upstream about the proper way to fix it

Several hundred times a day is not "not that often". It is
a gross malfeature, a major speed bump for non-technical users
and a constant source of irritation.

Sometimes when I click on a jpg file, I can actually see the
dialog change from "Open with GQview" to ... nothing. It's
literally someone who knows that I am too stupid to use a
computer, slapping my hand and saying, "

____________________________________________________________________________________
Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now.

Revision history for this message
Steve K (steve10k) wrote :

--- Sebastien Bacher <email address hidden> wrote:

> it doesn't happen that often and such comment are not really
> useful, if you want to get that bug fixed the best way would
> probable to talk with upstream about the proper way to fix it

A couple of hundred times a day is not "not that often". It is
a gross malfeature: A major speed bump for non-technical first
time users (supposedly the target audience for Ubuntu), and a
constant daily irritation for the rest of us.

User to computer: "Open jpg files with GQView."

Computer to user: "Do you think you f***ing own me?"

User to Ubuntu: "Hey, this thing is broken."

Ubuntu to user: "Tell someone who cares."

____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

Revision history for this message
Sebastien Bacher (seb128) wrote :

For most of users it works just fine, maybe you face a buggy case where the mimetype database should be fixed though. If you want to get that fixed the right way would be to attach an example of file not opening fine on your box so we can fix it instead of complaining it happens hundred of times a day.

Revision history for this message
Carsten Schneemann (carsten-schneemann) wrote :

Sorry for so long without notice.
On my box this problem occurs with _every_ pdf file. I have no problems with e.g. jpg files or so. As an example I attach one of the files for which I verified that it doesn't open upon double-clicking (giving the cited error message instead).

Revision history for this message
Caminomaster (caminomaster) wrote :

I've attached detailed files with a comment when I reported the bug as #57038, with the related information.
Maybe I can add more imformation (see the images):

1. try to open file, and get the horror message.
2. Open the file with rightclick>open with>gthumb, then
3. See the image
4. Switch to folder, and there's no .jpg images
5. Back to image wiew, there's neither jpg images

Wiht gnome eye is the same thing, and that is a very boring- serious and inproductive problem; note that you cannot see multiple jpg's, or must open one-by-one...

I had to install a windows viewer in order to use it with wine, but obviously thit is not the right way things must be.
P.D: These wine-through application don't get the problem, but i must open the file from inside application.(Irfanview)

Revision history for this message
Sebastien Bacher (seb128) wrote :

Carsten, Caminomaster, could you open new bugs about that, so we don't bug flood people subscribed to that bug which is not about detection mistakes themself but what nautilus does when they happen

Revision history for this message
Kees Cook (kees) wrote :

Is there some way to get gnome to report the source of the MIME values? For example, having something like:

 gnomevfs-info --source-source image.jpg
 /usr/blah/mime.something: JPEG Image
 /home/user/.local/mime/blah.mime: jpg document

Are the MIME "source file" locations kept when loading the MIME database?

Revision history for this message
Sebastien Bacher (seb128) wrote :

There is no command for that Kees, the mimetype database is made from the .desktop installed and the cache is located to /usr/share/applications/mimeinfo.cache, the user version is ~/.local/share/applications/mimeinfo.cache. What do you mean by 'Are the MIME "source file" locations kept when loading the MIME database'?

Revision history for this message
Kees Cook (kees) wrote :

On Sun, Feb 18, 2007 at 07:49:47PM -0000, Sebastien Bacher wrote:
> There is no command for that Kees, the mimetype database is made from
> the .desktop installed and the cache is located to
> /usr/share/applications/mimeinfo.cache, the user version is
> ~/.local/share/applications/mimeinfo.cache. What do you mean by 'Are the
> MIME "source file" locations kept when loading the MIME database'?

I mean, as the MIME information is loaded from the .desktop files, and
all the other sources, is the "original location" of the MIME info
stored in the cache? (If not, perhaps this should be added to help
folks track down where a given MIME type came from.)

--
Kees Cook @outflux.net

Revision history for this message
Sebastien Bacher (seb128) wrote :

there is no mention of the location no, that's not really useful though, you have one user directory to look at and then at the system one

Revision history for this message
Sebastien Bacher (seb128) wrote :

This upload allows you to set a gconf key to not get thar dialog:

 nautilus (2.18.0.1-0ubuntu2) feisty; urgency=low
 .
   * debian/patches/08_display_mimetype_warning.patch:
     - new "preferences/display_mimetype_warning" gconf key which allow to use
       or not the mismatching mimetype warning dialog (Ubuntu: #19101)

Don't closing the bug yet, it would be nice to have a "open anyway" button on the warning dialog, if somebody wants to work on it ... ;)

Revision history for this message
Jeffrey Knight (jeffrey-knight) wrote :

I can confirm this "bug" (feature?). I installed 7.04 from scratch, and moved my home dir over from my old Ubuntu laptop. When I try to open png files I get the error:
" The contents of the file indicate that the file is of type "PNG image". If you open this file, the file might present a security risk to your system."

My "fix" was:
$ mv ~/.local/share/applications/mimeinfo.cache ~/.local/share/applications/mimeinfo.cache.backup
$ update-mime-database ~/.local/share/mime

Revision history for this message
Haz (haz2a) wrote :

I had the same problems after a recent upgrade from Dapper 6.06LTS to Edgy 6.10. It particularly affected HTML and XML files which I noticed first in yelp - it opened these files in gedit. I also had similar problems with icons like bug 41772. With .tar.gz archives I also got the message "No application suitable for automatic installation is available for handling this kind of file".

The steps below fixed all these problems for me:-

It did not seem to be necessary to move or rename ~/.local/share/applications/mimeinfo.cache as reported by jefight for 7.04. I did actually do that first, but when I restored it again after step 3 below, the problems remain fixed.

1. sudo update-mime-database /usr/share/mime

2. sudo dpkg-reconfigure shared-mime-info

3. $ killall gnome-panel
    $ killall nautilus

Haz

Revision history for this message
Tristan Wibberley (tristan-wibberley) wrote :

Regarding Sebastien's suggestion of adding an "open anyway" button. If you put in such a button most users will just press it without regard to the monologue text. So there would be no point having the monologue at all - it would just be annoying.

What problem is this message actually supposed to solve? Nautilus has worked out what the file type is, so it knows which program can open it.

Revision history for this message
Sebastien Bacher (seb128) wrote :

The default would be on cancel and the text explains to user that they are trying to open a file which has a content different of what the filename indicates which could be a trojan

Revision history for this message
Tristan Wibberley (tristan-wibberley) wrote : Re: [Bug 19101] Re: nautilus's clever anti-hax0r detection is really dumb

On Sun, 2007-05-13 at 15:00 +0000, Sebastien Bacher wrote:
> The default would be on cancel and the text explains to user that they
> are trying to open a file which has a content different of what the
> filename indicates which could be a trojan

That risk could only ever occur if one tries to run a program/script. In
which case, issuing a warning that a program/script is about to be
executed would be more appropriate and prevents this "bug" occuring for
all other filetypes.

The real culprit here is simply that the feature is looking for a
difference between what type the file is and what type a windows user
will think the file is, when it should be looking for a difference
between whether the file is a script/program to be executed and whether
a user will expect a script/program to be started.

Most users shouldn't be running programs by double-clicking files in a
filesystem browser so I can't see that it is a sensible default. IMHO,
the ideal solution would be not to run programs and scripts but rather
open a metadata viewer with an execute feature. Same should go for debs,
too - open a metadata viewer which I think is what happens already. That
makes it clear to the user what the real type is and requires that they
be explicit that they want to run the program/install the package.

In that case I think the current feature should be limited to
scripts/elf/pe/debs etc and a spec started to stop running things on
double-click for the future.

What do you think?

--
Tristan Wibberley

Revision history for this message
Sebastien Bacher (seb128) wrote :

Limiting to things that can be runned might make sense, the discussion would be better placed upstream though since we are not making decisions for them and they might have some reason to not limit it to this case

Revision history for this message
sneezy (stephen-mckay-au) wrote :

This is probably not strictly a nautilus bug. But is damn annoying. What is happening is a mismatch in the mime-type definitions. In my case, (and I am using fedora 6, though I suspect Ubuntu will have the same issue and fix - s/o please test) the freedesktop.org.xml file in /usr/share/mime/packages lists the .exe extension as being "x-executable", when it should rather be "x-ms-dos-executable" and the Description field lists executable, instead of "DOS/Windows executable". Here is what it looks like (with out the language stuff):

<code>

  <mime-type type="application/x-executable">
    <comment>executable</comment>
    <magic priority="40">
      <match value="\177ELF" type="string" offset="0">
        <match value="1" type="byte" offset="5">
          <match value="2" type="little16" offset="16"/>
        </match>
      </match>
      <match value="\177ELF" type="string" offset="0">
        <match value="2" type="byte" offset="5">
          <match value="2" type="big16" offset="16"/>
        </match>
      </match>
      <match value="MZ" type="string" offset="0"/>
      <match value="0x521c" type="little16" offset="0"/>
      <match value="0420" type="host16" offset="0"/>
      <match value="0421" type="host16" offset="0"/>
      <match value="0603" type="little16" offset="0"/>
    </magic>
    <glob pattern="*.exe"/>
  </mime-type>

</code>

The fix (workaround) that works for me is to edit /usr/share/mime/packages/freedesktop.org.xml (as root) and change the following lines:

<code>

  <mime-type type="application/x-executable">
    <comment>executable</comment>

</code>

change to

<code>
  <mime-type type="application/x-ms-dos-executable">
    <comment>DOS/Windows executable</comment>
</code>

Once this has been done, you need to run (as root): "update-mime-database /usr/share/mime"

This should correct the problem. Other filename extensions can get mixed up, but the fix should basically be the same. Check the /usr/share/mime/packages directory for references to the wonkified extension or mime type and then edit the offending file to correct it. Once done, run the update-mime-database command to apply the changes to the system and bob's your uncle.

Cheers
Sneezy da Leprechaun

Revision history for this message
obaqueiro (obaqueiro) wrote :

I can confirm this bug, however it happens to me in Fedora Core 2.6.20-1.2948.fc6 , Gnome ver. 2.6.13

It is REALLY annoying and I guess it is a GNOME problem rather and an Ubuntu problem. I am attaching two screens with examples of the bug in "action". Originally I was going to attach the PDF example as it was the one that I was aware of, as I work a lot with PDFs everyday, however when trying to see the screenshot saved in the desktop I got same bug with the PNG error... so here it is as well.

IMHO there should be another button named "OPEN" and not only te cancel button!!! it is fine that you want to make your system very very secure but for us who just want to work this annoyance is just getting in our way.

Thank you!

Revision history for this message
itcrowd (itcrowd) wrote :

Hi All,

Don't know if this is fixed or not, but please find below what I had to do to fix it.

The error I had is the exact same as the one outlined in the bug description.

I downloaded Java3d in a tar.Z file and everything was fine, I got the error message when I tried to open it and whenever I tried to open a .html file from then on. ("Like all of us, its not my fault its something the computer did")

Anyway, headed for terminal, typed "nautilus-file-management-properties&"

When the file manager opens, click the 'List Columns' Tab, and check the 'MIME Type' check box, and click closed.

Go to a folder that contains a sample of the type of file you can't open, (the problem file type I had was '.html'). Its 'Type' was 'html document', and you should now be able to see it's 'MIME Type'. My 'MIME type' was 'application/x-extension-html', but when I clicked the file,its Icon changed from white page to a web-browser icon, its Type changed to HTML document and its MIME Type changed to text/html. And I was left with the 'right click to open scenario as outlined above'.

Anyway cut to the chase, after a bit of net-surfing, I found that all the MIME info is stored in /usr/share/mime/, and in either 'text', 'application', etc sub-folders. But MIME details are also stored in your home folder under .local/share/mime.

Inside the home directory MIME folder, I found application and packages folders, and a few other files, one of which was called 'globs' which contained:

'appllication/x-extension-html:*.html'

In the application folder was a 'x-extension-html.xml' file and in the packages folder was a file called 'Override.xml'.

So I made a copy of the MIME folder in .local/share/mime, called it MIME1, deleted the MIME folder and rebooted and it works as per normal now.

Click a 'html' file and it opens in Firefox.

Don't you just love computers.

Note: this seems like a very fast fix (and it is, should take about 5 minutes to fix), but it took about 6 hours yesterday and about 4 hours today, with searching and playing around until I found came up with the details above

Bye for now.

itcrowd

Changed in nautilus:
status: Confirmed → Triaged
Revision history for this message
Daniel T Chen (crimsun) wrote :

(Importance seems inflated - demoting.)

Changed in nautilus:
importance: Medium → Wishlist
Revision history for this message
Sebastien Bacher (seb128) wrote :

the bug is fixed in the current nautilus gio version

Changed in nautilus:
status: Triaged → Fix Released
Changed in nautilus:
status: Confirmed → Invalid
Changed in nautilus:
importance: Unknown → High
status: Invalid → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.