Comment # 3 on bug 1201122 from Dirk Weber

Small test script to prove that really the garbled output of "file" in case of
files with multi-byte characters in the filename is the culprit.
This script can also be used as a temporary workaround.

create a file
~/bin/file

with the content  between "----"
----
#!/bin/bash
NAME=$(/usr/bin/file -b "$@")
echo "${BASH_ARGV[0]}: $NAME"
----

explanation:
the bin directory of the user is in the path before /usr/bin - this can be
verified by
echo $PATH

Therefore mc will then call this script instead of /usr/bin/file

The script in turn calls /usr/bin/file but with the additional parameter "-b"
which tells file  (file --help):
  -b, --brief                do not prepend filenames to output lines

then the script creates the output as expected by mc-4.8.28-2.1.x86_6 by
prepending the correct filename and a colon.

Example:
file -z -S -L /home/user/test���������������������������.jpg 
/home/user/test���������������������������.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI),
density 72x72, segment length 16, baseline, precision 8, 600x800, components 3


/usr/bin/file -z -S -L /home/user/test���������������������������.jpg 
/home/user/test\342\202\254\342\202\254\342: JPEG image data, JFIF standard
1.01, resolution (DPI), density 72x72, segment length 16, baseline, precision
8, 600x800, components 3


In this way mc can again open files with multi-byte characters in the filename
for which it uses the type keyword in the mc.ext.

This also shows that the actual bug is in 
file-5.42-1.1.x86_64