Re: jpegs throwing up 'ambiguous filetype' dialog
- From: Phil Grundig <wdef200@xxxxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Sun, 18 Jan 2009 18:44:51 +0000 (GMT)
--- On Sun, 18/1/09, Phil Grundig <wdef200@xxxxxxxxxxx> wrote:
> From: Phil Grundig <wdef200@xxxxxxxxxxx>
> Subject: Re: jpegs throwing up 'ambiguous filetype' dialog
> To: emelfm2@xxxxxxxxxxxxx
> Date: Sunday, 18 January, 2009, 6:33 PM
> Hi, thanks for the prompt responses.
>
> I got carried away(!!) and spent a bit of time this weekend
> going through the sources.
>
> Please note the discussion below is with reference to
> emelfm2-0.4 since emelfm2-0.5 was not compiling for me on
> dsl (I suspect that is a dual glib issue and will be fixed
> with a reboot - my apologies).
>
> Walther.is correct: the "ambiguous file' dialog
> arises if a jpeg has executable owner perms for some
> unintentional reason or if the jpegs are on a FAT-type
> partition so the file is seen as world executable.
>
> Around line 1977 in e2_task_backend.c the exec variable is
> set by a call to e2_fs_access. If e2_fs_access sees x perms
> on the file then exec is true.
>
> However, it seems the 'file' utility never gets
> called to check if the jpeg really is an executable, as it
> would do if (say) e2_fs_is_executable (around line 450 in
> e2_fs.c) got called instead.
>
> So for this jpeg, now have exec = 1 ext = jpg action =
> _xzgv@xzgv real_action = xzgv ask = 1
>
> Which then throws up the ambiguous file dialog.
>
> I have attached a patch that gets rid of this for
> illustrative purposes by calling _e2_fs_grep_file_output to
> correct the value of exec if it is wrong (ie if the jpeg is
> not an executable according to 'file'). Only 3
> files are actually changed; changes are marked with a
> comment containing 'phil hack'.
>
> Please note I don't think this is really a proper fix,
> just a proof of concept only to illustrate the above. It
> has the side effect of breaking symlink handling eg if click
> on a symlink to an executable, it throws a different dialog
> to get the action rather than executes (might have other
> side effects as well).
>
> Hope this is helpful, thanks for emelfm2.
>
> -phil
BTW I was a bit sloppy making that patch - you should probably prune it to
remove unwanted changes (such as build.h)
--
Users can unsubscribe from the list by sending email to
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by
logging into the web interface.
Other related posts:
