Comment # 1 on bug 1201122 from Dirk Weber

according to ltrace on mc's PID it executes "file" in order to determine the
file type, and at this point the filename is correct 

ltrace -fi -p 4953 -s 256  -o broken3.txt

...
6142 [0x55cbe7590aec] strcpy(0x55cbe87c0210, "file -z -S -L
/home/user/test\342\202\254.jpg 2>/dev/null")     = 0x55cbe87c0210
...
4953 [0x5633f9a2d350] strchr("/home/user/test\\342\\202\\254.j: JPEG image
data, JFIF standard 1.01, resolution (DPI), density 72x72, segment length 16,
baseline, precision 8, 600
4953 [0x5633f9a2d360] strlen("/home/user/test\342\202\254.jpg")                
                              = 22
...

strange is that in the output of "file" the filename is not complete: 2
characters are missing.

This can also be reproduced on the command line for files with multi-byte
characters, but not for other even longer filenames:

user@factory:~$ file test_longer_name.jpg
test_longer_name.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI),
density 72x72, segment length 16, baseline, precision 8, 600x800, components 3
user@factory:~$ file test���������.jpg
test\342\202\254.j: JPEG image data, JFIF standard 1.01, resolution (DPI),
density 72x72, segment length 16, baseline, precision 8, 600x800, components 


File names with more multi-byte characters are more truncated in the output of
"file":

user@factory:~$ file test������������������������������������.jpg
test\342\202\254\342\202\254\342\202: JPEG image data, JFIF standard 1.01,
resolution (DPI), density 72x72, segment length 16, baseline, precision 8,
600x800, components

In the ltrace output of mc I do not see that mc uses the broken filename from
file, therefore I would currently think that this is not the reason for the
failure to open the file.