Ticket #4377 (closed defect: fixed)

Opened 4 months ago

Last modified 3 months ago

"Image Open"/"Image View" does not work with special character in filename

Reported by: ro-ee Owned by: andrew_b
Priority: minor Milestone: 4.8.29
Component: mc-core Version: 4.8.28
Keywords: image, open, view, special characters Cc:
Blocked By: Blocking:
Branch state: merged Votes for changeset: committed-master

Description

If I have an image file with either a special character (≥ U+0080) in it, for example German umlauts, or special punctuation (’, “, », …) in it, or in the path of it, it won’t be recognized as image, and pressing Enter (to open) or F3 to view won’t work.

"Image view" (F3) on the file then shows the hex view of the file instead of the image info usually displayed with images.

It works with video files though, so this seems limited to the image file detection.

Change History

comment:1 Changed 4 months ago by ro-ee

After reading the text, I would like to add that of course the file name (or the path) is meant when I wrote 'with a special character in it', not the content of the files (of course).

so: create an image file with the name "testö.jpg" or put an image file in a folder named "testö", MC won’t be able to open it with Enter or View the file info with F3.

It will work with an mp4 file, though (and call your video player of choice), so "testö.mp4" or a folder named "testö" will work.

comment:2 Changed 4 months ago by andrew_b

Works for me.

Please temporarily remove ~/.config/mc/mc.ext and try again.

comment:3 follow-up: ↓ 4 Changed 4 months ago by ro-ee

Removing mc.ext or even completely removing .config/mc: still the same (also if I use another account on the same computer).

I am not able to find a global mc.ext that might be used instead.

My locale is
LANG="en_US.TF-8"
LC_CTYPE="en_US.UTF-8"

I added debug code to the /usr/libexec/mc/ext.d/image.sh to see if it even gets called, which is not the case (I have since reverted back these changes, to make sure this isn’t the source of further issues)

Is there a way to print out the mc.ext which is currently in use? (i.e. the built-in one)?

One add: this is the same for jpg, gif and png files (I’m only writing this because in the current mc.ext (which I have since renamed), JPEG is the only one which adds one additional View command, the PNG, GIF, ... files directly refer to the Include=image part.

comment:4 in reply to: ↑ 3 Changed 4 months ago by andrew_b

Replying to ro-ee:

I am not able to find a global mc.ext that might be used instead.

mc -F shows all directories used by mc.

My locale is
LANG="en_US.TF-8"
LC_CTYPE="en_US.UTF-8"

I added debug code to the /usr/libexec/mc/ext.d/image.sh to see if it even gets called, which is not the case (I have since reverted back these changes, to make sure this isn’t the source of further issues)

Is there a way to print out the mc.ext which is currently in use? (i.e. the built-in one)?

Usually, global mc.ext is /etc/mc/mc.ext. There is no any built-in one.

comment:5 follow-up: ↓ 6 Changed 3 months ago by dimich

"type" key in mc.ext doesn't work properly with non-ascii file names because file utility replaces non-ascii characters in output to its octal codes and distorts a name. Midnight Commander then compares this name to supplied name (in ext.c:regex_check_type()) and calculates content_shift incorrectly, thus mc_search_new() fails.
It would be good to use --brief option of file if it's supported on all platforms.
Also --mime option could make output parsing much easier and deterministic.

comment:6 in reply to: ↑ 5 ; follow-up: ↓ 9 Changed 3 months ago by andrew_b

Thank you for the analyzing.

Replying to dimich:

"type" key in mc.ext doesn't work properly with non-ascii file names because file utility replaces non-ascii characters in output to its octal codes and distorts a name.

Perhaps it depends on file version:

$ file testö.jpg
testö.jpg: JPEG image data, JFIF standard 1.02
$ file -v
file-4.26
magic file from /etc/magic:/usr/share/file/magic

It would be good to use --brief option of file if it's supported on all platforms.

It's a good idea.

Also --mime option could make output parsing much easier and deterministic.

Cannot see any the useful info:

testö.jpg, 1: Warning: offset `����' invalid
testö.jpg, 1: Warning: type `����' invalid
testö.jpg, 2: Warning: offset `��Mh�b���^���E\XJH6=�\W>_��^�9*6\H������9����\� ��4      Ο' invalid
testö.jpg, 2: Warning: type `��Mh�b���^���E\XJH6=�\W>_��^�9*6\H������9����\� ��4  [���Ο' invalid
�Hcy�����b 3: Warning: offset `p��X����^���T�hc��Ҹ�0E_��c���eI.�������k         [���5�
          �;Ԍ&L���އ �B4mc��7��' invalid
�Hcy�����b 3: Warning: type `p��X����^���T�hc��Ҹ�0E_��c���eI.�������k
          �;Ԍ&L���އ �B4mc��7��' invalid
testö.jpg, 4: Warning: offset `��iчY4r[`GH�Oή��"4�U���ƌ�E

Perhaps it depends on file version too.

comment:7 Changed 3 months ago by ro-ee

I have file version 5.42

alex@horus:~> file -v
file-5.42
magic file from /etc/magic:/usr/share/misc/magic
seccomp support included

and get

alex@horus:~> file testö.jpg 
test\303\266.jp: JPEG image data, JFIF standard 1.01, resolution (DPCM), density 118x118, segment length 16, progressive, precision 8, 1706x1132, components 3

notice that even the 'g' is missing in the filename.

Still, what I don’t understand that this does not happen with videos? or isn’t 'file' not invoked in all cases, and .mp4 files are detected by other means?

using the --raw/-r parameter on 'file' will print the correct character (or leave the character as-is), but it still gets shortened by one character:

alex@horus:~> file testö.jpg -r
testö.jp: JPEG image data, JFIF standard 1.01, resolution (DPCM), density 118x118, segment length 16, progressive, precision 8, 1706x1132, components 3
Last edited 3 months ago by ro-ee (previous) (diff)

comment:8 Changed 3 months ago by ro-ee

From a bug report in opensuse forums, where I first reported this,

https://forums.opensuse.org/showthread.php/571604-(%E2%89%A5-0x80)?p=3137435#post3137435

it looks like a patch made to 'file' on May 28th is to blame. There is something wrong with the patch (even in -raw mde, because of the shortening of the file name), but I think going with the -b option is the better route to take.

comment:9 in reply to: ↑ 6 Changed 3 months ago by dimich

Replying to andrew_b:

Perhaps it depends on file version

Filename conversion was introduced recently by this commit: https://github.com/file/file/commit/f448f3e5c37de8c285ac14b032b2bdcea82fc08b and it is already in file-5.42.

Also --mime option could make output parsing much easier and deterministic.

Cannot see any the useful info

$ file --brief --mime-type /tmp/testö.jpg 
image/jpeg
$
$ file -v
file-5.42
magic file from /usr/share/file/misc/magic
seccomp support included

Replying to ro-ee:

Still, what I don’t understand that this does not happen with videos? or isn’t 'file' not invoked in all cases, and .mp4 files are detected by other means?

In default mc.ext videos are detected by filenames with "shell/regex" keys, not by "type".

comment:10 Changed 3 months ago by andrew_b

  • Status changed from new to accepted
  • Owner set to andrew_b

comment:11 Changed 3 months ago by andrew_b

  • Branch state changed from no branch to on review
  • Milestone changed from Future Releases to 4.8.29

Branch: 4377_file_b
Initial changset:0bb9c0472033962aea4b682097d953fee73f01c2

Version 0, edited 3 months ago by andrew_b (next)

comment:12 Changed 3 months ago by andrew_b

  • Votes for changeset set to andrew_b
  • Branch state changed from on review to approved

comment:13 Changed 3 months ago by andrew_b

  • Status changed from accepted to testing
  • Votes for changeset changed from andrew_b to committed-master
  • Resolution set to fixed
  • Branch state changed from approved to merged

Merged to master: [ab63cd2a9454a51e8e654778f486caf820d6da06].

git log --pretty=oneline 6c4520874..ab63cd2a9

comment:14 Changed 3 months ago by andrew_b

  • Status changed from testing to closed
Note: See TracTickets for help on using tickets.