Mimetype error: *.exe => the filename indicates "executable", while the contents indicated "DOS/Windows executable"

Bug #91636 reported by Ralf Nieuwenhuijsen
14
Affects Status Importance Assigned to Milestone
wine (Ubuntu)
Fix Released
Undecided
Scott Ritchie

Bug Description

Binary package hint: wine

When I click on a .exe file with the intention of running it with WINE, I get the following message:

=== Message in the MessageBox ===

The filename "FarCryAutoCD.exe" indicates that this file is of type "executable". The contents of the file indicate that the file is of type "DOS/Windows executable". 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 "DOS/Windows executable", then open the file normally. Alternatively, use the Open With menu to choose a specific application for the file.

=== End of Message ===

Although its slightly funny, it sure looks like a bug. The mime-type associated with the .exe extension should be "DOS/WIndows execute" and not "executable"

I'm not entirely sure which package to file this bug with, so i've set it up for wine. But perhaps the whole mime-type dealing stuff is somewhere else ..

Revision history for this message
David Oxland (doxland) wrote :

I have the same problem for some reason when trying to open a program called"emailstripper.exe" and I get the above messae. It will open if I direct it to, and choose wine to open with but will not open by simply clicking on it. I also changed it's permisson to executable but no change.

Revision history for this message
Ric B (yelloweverything) wrote :

I had this problem, and came here looking for my solution to it. I never "fixed" the bug, but I found a work-around. Renate the extenstion to .EXE (in uppercase) and it works like a charm.

Revision history for this message
Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen) wrote :

Yeah, I do hope the wine-maintainer fixes this. Herman are you there? ;-)

I didn't even have wine associated with .exe files in the first place.

I had to manually add it.
Interestingly, griffin (a movie catalog program) was associated with it.
Perhaps something more sinister is going on?

Changed in wine:
status: Unconfirmed → Confirmed
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.
I found a fix as reported in bug 19101.

Revision history for this message
Philip A. Marshall (philip-philipamarshall) wrote :

This seems to be fixed in Feisty. I haven't encountered the problem since I upgraded.

Revision history for this message
rai4shu2 (rai4shu2) wrote :

This is NOT fixed in Feisty, and I have seen it several times already. Furthermore, in a console, it gives the following error:

run-detectors: unable to find an interpreter for
/path/to/program.exe

Several things in mono rely on this functioning properly, and I cannot just alter the program to force to execute "wine program.exe" instead.

Revision history for this message
rai4shu2 (rai4shu2) wrote :

Sorry, but I should have said that this no longer works with version 0.9.36 or newer. It works fine, however, with 0.9.33.

Revision history for this message
Stephan Rügamer (sruegamer) wrote :

When I set chmod 755 to the exe file on the cli and starting it via ./exefile, the exe is being executed correctly with wine-auto.
Nevertheless, clicking in nautilus on an exe file, it gives me your presented error message.

But, this is a behaviour we want for security reasons.
Wine is also able to run windows viruses, and that's something we don't want.

I'll move the bug report to nautilus, just because there is the one and only place to look for a solution.

(Discussed with pitti and kees @ irc, 2007-05-15)

Revision history for this message
Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen) wrote :

"But, this is a behaviour we want for security reasons. But, this is a behaviour we want for security reasons. Wine is also able to run windows viruses, and that's something we don't want."

I am sorry but I completely disagree.

You want a irrelevant warning about mismatching file-extensions and mime-types, that only occurs if the file-extension is lower-case, to protect us from windows viruses that can't infect the rest of the linux-system anyway?

My issues with this logic:
 1) the error message is unrelated. It is about .exe not matching wine-executables mime-type. (a screenshot very thedailywtf.com worthy)
 2) the error message is only showed when the file-extension is lowercase
 3) wine does not tear down linux' user-level security. wine is just as safe as a linux executable running under the user.
 4) wine is unlikely to be vulnerable to the same exploits as microsoft's code: its a completely different codebase
 5) windows executables may in practice be less safe because windows is targeted more and has more clueless users. But when we fix bug number 1, this will change anyway. We may _not_ depend on this. This is not an intelligent strategy.

How I think it should behave:
  1) double clicking any executable (wine, linux, shell-script), that has executable permission set, should launch immediately
  2) both lowercase and uppercase .exe extensions would be recognized as wine-executables and behave just as a native linux executable
  3) when double clicking an executable file that has no executable flag set, the user is asked whether or not it want to execute the file. This question should have a remember-my-choice field that turns the executable on, if the user has the permission to do so with that file. Perhaps I should file a bug report about this for the package nautilus?

Here's a rule of thumb about allowing users to run 'untrusted' software: asking is ok, preventing is not, confusing is worse.
Protecting dumb users at the expense of functionality is not our job. Bugs in the users, should be filled and fixed upstream. Please post those bugs at one these websites:
   http://bugs.launchpad.net/adam
   http://bugs.launchpad.net/eve

I also would like to point out that wine is not installed by default. It is installed by choice. Choice.
It should be possible to launch steam-setup.exe from the desktop after downloading it.

Forcing the usage of the terminal is NOT ACCEPTABLE. And doing it because you think we are dumb is patronizing. We are talking about linux users here. People that actually choose to run linux are unlikely to double click hot-porn.exe . And when the day comes Ubuntu actually has those type of users, it will be called hot-porn.deb anyway.

Revision history for this message
Hanusz leszek (leszek-skynet) wrote :

I agree completely with Ralf.
Is there a way to unmark my bug as a duplicate of this one ?
https://bugs.launchpad.net/ubuntu/+source/wine/+bug/113706

Revision history for this message
rai4shu2 (rai4shu2) wrote :

Please correct me if I'm wrong, but is this problem addressed here? https://bugs.launchpad.net/ubuntu/+source/wine/+bug/85338

If this is the direction that Wine should be taking from now on, maybe someone should notify Scott Ritchie (considering the newer versions of Wine still include "wine.desktop", etc).

Changed in wine:
assignee: nobody → ubuntu-wine
Revision history for this message
Scott Ritchie (scottritchie) wrote :

Hardy will be using a different MIME-type handler for Windows executables. See https://wiki.ubuntu.com/BetterIntegratedWineSpec

Changed in wine:
assignee: ubuntu-wine → scottritchie
status: Confirmed → Fix Released
Revision history for this message
setreset1 (setreset1) wrote :

I had the same problem with text files ending with .dat .

I didn't like the usual solutions, involved lengthy command lines.

I finally solved this today using an application: "File Types Editor" for mime types. You just go there to the type of file and change its definition.

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.