id summary reporter owner description type status priority milestone component version resolution keywords cc blockedby blocking branch_state votes 4649 Fix mc.ext.in rules order to avoid content handlers taking precedence over archive handlers zaytsev "See also: #4128, #4419 ---- Feedback from Ubuntu user: https://bugs.launchpad.net/ubuntu/+source/mc/+bug/2097560 I have a zip file where the first enclosed file is PDF. For a reason (I strictly prefer okular over evince and was lazy to find another place to set the priority), I changed the mc extension file (mc.ext) entry to the following: {{{ type/^PDF Open=okular %f & disown }}} Unexpectedly, this caused misopening of some zip files. Checking what is happening by strace showed that mc calls `file` with arguments to detect the enclosed contents: {{{ 1368162 19:40:43.017932 execve(""/usr/bin/file"", [""file"", ""-z"", ""-S"", ""-L"", ""/home/netch/Downloads/sql_12.zip""], 0x6017f1d3d398 /* 68 vars */ }}} and this file helper returns: {{{ 1368162 19:40:43.040724 write(1, ""PDF document, version 1.3, 90 pages (Zip archive data, at least v2.0 to extract, compression method=deflate)\n"", 109) = 109 }}} The rule in the extension file detects, according to `""^PDF""`, this is PDF and runs `okular` instead of `ark` for this file. Okular deliberately rejects opening zip. With the default extension file contents: {{{ Open=/usr/lib/mc/ext.d/doc.sh open pdf }}} the bug still has place but is masked because passing through `doc.sh` and then `xdg-open` rechecks the file type using `file` (technically, with `kioslave5`) without `-z` that allows proper detection. So using simple `file/` rules in mc extension file is incompatible with using `file -z` for deeper analysis (if this deeper analysis has sense in general). Iʼm uncertain for security impact but it could have taken place in a more complicated scenario." enhancement new major Future Releases mc-core master ossi no branch