Ticket #4180 (closed defect: fixed)
mc 4.8.26: cannot view content of .xpi archives (firefox extensions, aka zip files with .xpi extension)
Reported by: | gv | Owned by: | andrew_b |
---|---|---|---|
Priority: | major | Milestone: | 4.8.27 |
Component: | mc-core | Version: | 4.8.26 |
Keywords: | Cc: | ossi, jg.staffel@…, onlyjob@… | |
Blocked By: | Blocking: | ||
Branch state: | merged | Votes for changeset: | committed-master |
Description
Up to mc 4.8.25 you can view the content of firefox extensions (.xpi files). This is not possible anymore.
The error message is:
Cannot open "/path/to/ff_ext.xpi" in parse mode No such file or directory (2)
If I renaming .xpi archive to .zip , mc display the content just fine:
$ file ff_ext.xpi ff_ext.xpi: Zip archive data, at least v1.0 to extract $ cp ff_ext.xpi ff_ext.zip $ file ff_ext.zip ff_ext.zip: Zip archive data, at least v1.0 to extract
F3 on ff_ext.zip display list of files in the archive.
However:
$ zip archive some-dummy-file.txt adding: some-dummy-file.txt (deflated 66%) $ file archive.zip archive.zip: Zip archive data, at least v2.0 to extract
F3 on archive.zip display list of files in the archive.
$ cp archive.zip archive.xpi
F3 on archive.xpi and mc display the content of some-dummy-file.txt instead of archive filename list.
$ zip archive1 some-dummy-file.txt another-dummy-file.txt adding: some-dummy-file.txt (deflated 66%) adding: another-dummy-file.txt (deflated 66%) $ file archive1.zip archive1.zip: Zip archive data, at least v2.0 to extract $ cp archive1.zip archive1.xpi
F3 on archive1.xpi and the same message is shown:
Cannot open "/path/to/archive1.xpi" in parse mode No such file or directory (2)
Change History
comment:1 follow-up: ↓ 2 Changed 4 years ago by andrew_b
- Cc ossi added
- Status changed from new to accepted
- Component changed from mc-vfs to mc-core
- Branch state changed from no branch to on review
- Owner set to andrew_b
comment:2 in reply to: ↑ 1 Changed 4 years ago by gv
Sorry, but there is no mc.ext in ~/.config/mc. Instead I changed /etc/mc/mc.ext.
Still, I get the same error message. After the dialog is dismissed, mc show the raw content of the archive (the same you get with Shift-F3) instead of the list of files in the archive. Pressing enter on the xpi file does nothing.
comment:3 Changed 4 years ago by andrew_b
Sorry, I cannot reproduce that. Please check your files again.
comment:4 Changed 4 years ago by gv
I did not quit mc after I changed mc.ext. It works fine now.
Thank you.
comment:5 Changed 4 years ago by andrew_b
Ticket #4183 has been marked as a duplicate of this ticket.
comment:6 Changed 4 years ago by andrew_b
- Votes for changeset set to gv andrew_b
- Branch state changed from on review to approved
comment:7 Changed 4 years ago by andrew_b
- Status changed from accepted to testing
- Votes for changeset changed from gv andrew_b to committed-master
- Resolution set to fixed
- Branch state changed from approved to merged
Merged to master: [a75071b3c07d7dc2795ad2c321e1e340eceadb24].
comment:9 Changed 4 years ago by alpir
- Status changed from closed to reopened
- Resolution fixed deleted
After applying the patch, zip archives began to open, but open with an error:
file -L -z archive.zip: Bad system call
This caused by using /usr/bin/file with -z option (src/filemanager/ext.c), because seccomp doesn't allow it. The problem is seccomp, a security sandbox. Security is more important than usability, so if we actually need -z, we should generally also use -S.
comment:11 Changed 4 years ago by ossi
my manual contains this nice blurb:
Note: This Debian version of file was built without seccomp support, so this option has no effect.
which is why i never noticed that this option was introduced at some point.
i'll note that a sandbox that cripples the host program is somewhat "sub-par". a proper implementation would use a non-sandboxed helper process for spawning essential children (which would ideally run inside a sandbox in turn).
i suppose adding -S is the way forward.
comment:12 Changed 4 years ago by alpir
Gentoo x64,sys-apps/file-5.39-r3 has default USE flag seccomp. As far as I know, file is also built with this option in Arch.
comment:14 Changed 4 years ago by andrew_b
- Votes for changeset committed-master deleted
- Version changed from 4.8.26 to master
- Branch state changed from merged to on review
Branch: 4180_file_S
changeset:e43c9e6431fe21110097a63cd3f1fd1b35e6353e
comment:15 Changed 4 years ago by ossi
i'd swap the use order of FILE_L and FILE_S, as -S is related to -z.
also, the else-branches in the AC_DEFINEs should use empty strings, not spaces.
comment:16 Changed 4 years ago by ossi
on a mildly related note, it would probably make sense to also check for -z, and just error out if that fails (as implementing an alternative path for that seems kinda impractical).
comment:17 Changed 4 years ago by andrew_b
[ec1938db8ef8171440e1a56aea94feec59d23f71]
If file doesn't accept the -z options, it unused at all.
comment:18 Changed 4 years ago by ossi
not reviewed in context and not tested, but what i see looks good.
fwiw, there is an excess space on line 134 after the comma.
comment:19 Changed 4 years ago by andrew_b
Ticket #4208 has been marked as a duplicate of this ticket.
comment:20 Changed 4 years ago by andrew_b
- Votes for changeset set to andrew_b
- Branch state changed from on review to approved
comment:21 Changed 4 years ago by andrew_b
- Status changed from reopened to closed
- Votes for changeset changed from andrew_b to committed-master
- Resolution set to fixed
- Branch state changed from approved to merged
Merged to master: [c9cf22d458709dad97cd2b6cacd61db66178e381].
comment:22 Changed 4 years ago by gv
- Status changed from closed to reopened
- Resolution fixed deleted
It's still not 100% fixed.
$ file -L image.zip image.zip: Zip archive data, at least v2.0 to extract
$ file -L -z image.zip image.zip: JPEG image data, JFIF standard 1.01, resolution (DPI), density 96x96, segment length 16, baseline, precision 8, 1024x768, frames 3 (Zip archive data, at least v2.0 to extract)
Since in file mc.ext
type/^JPEG
is evaluated before
type/\(Zip archive
mc assume image.zip is a image not an archive.
Moving "### Plain compressed files ###" section before "### Images ###" fix the above problem.
comment:23 Changed 4 years ago by andrew_b
- Votes for changeset committed-master deleted
- Version changed from master to 4.8.26
- Branch state changed from merged to on review
Branch: 4180_mc.ext_archives
changeset:c3848a689c0323ba7958e2943878fe831369af01
comment:24 Changed 4 years ago by gv
Works fine. Thank you.
comment:25 Changed 4 years ago by andrew_b
- Votes for changeset set to gv andrew_b
- Branch state changed from on review to approved
comment:26 Changed 4 years ago by andrew_b
- Status changed from reopened to closed
- Votes for changeset changed from gv andrew_b to committed-master
- Resolution set to fixed
- Branch state changed from approved to merged
Merged to master: [fa2cbd2a2c7e38ee56d1756eac5899b57f7f4262].
comment:27 Changed 3 years ago by sorin
I am wondering if that is the same bug which prevents browsing of python wheels (.whl) on my macos box.
$ file some.whl
some.whl: Zip archive data, at least v2.0 to extract
$ file -L -z some.whl
some.whl: ERROR:[gzip: Unknown compression format] (Zip archive data, at least v2.0 to extract)
Sadly, even after compiling and installing the head version, it appears that mc is unable to browse zip or whl archives.
comment:28 Changed 3 years ago by andrew_b
You should sync your user's mc.ext with system-wide one.
Currently, I'm using 4.8.26-214-ga81f1ca19. It works fine:
$ file -L Django-1.8.4-py2.py3-none-any.whl Django-1.8.4-py2.py3-none-any.whl: Zip archive data, at least v2.0 to extract $ file -L -z Django-1.8.4-py2.py3-none-any.whl Django-1.8.4-py2.py3-none-any.whl: ASCII Java program text (Zip archive data, at least v2.0 to extract) $ /usr/lib/mc/extfs.d/uzip list Django-1.8.4-py2.py3-none-any.whl | head -n 10 -rwxrwxr-x 1 500 500 115 08/18/2015 12:55:12 ./Django-1.8.4.data/scripts/django-admin.py -rw-rw-r-- 1 500 500 10 08/18/2015 12:55:14 ./Django-1.8.4.dist-info/DESCRIPTION.rst -rw-rw-r-- 1 500 500 1552 08/18/2015 12:55:14 ./Django-1.8.4.dist-info/LICENSE.txt -rw-rw-r-- 1 500 500 83 08/18/2015 12:55:12 ./Django-1.8.4.dist-info/entry_points.txt -rw-rw-r-- 1 500 500 1594 08/18/2015 12:55:14 ./Django-1.8.4.dist-info/metadata.json -rw-rw-r-- 1 500 500 7 08/18/2015 12:55:12 ./Django-1.8.4.dist-info/top_level.txt -rw-rw-r-- 1 500 500 110 08/18/2015 12:55:14 ./Django-1.8.4.dist-info/WHEEL -rw-rw-r-- 1 500 500 1300 08/18/2015 12:55:14 ./Django-1.8.4.dist-info/METADATA -rw-rw-r-- 1 500 500 327077 08/18/2015 12:55:14 ./Django-1.8.4.dist-info/RECORD -rw-rw-r-- 1 500 500 519 08/18/2015 12:54:50 ./django/__init__.py
comment:29 follow-up: ↓ 30 Changed 14 months ago by teras
Sorry to revive an old thread, but it seems that JAR files are (once more?) not recognized by mc. I don't have a ~/.config/mc/mc.ext.ini file, and the syntax of this file seems different than the one shown here. As usual, I can browse a regular ZIP file; the problem is with JAR files. Any clues?
This is the result of #4128. You should synchronize your local ~/.config/mc/mc.ext with system-wide /etc/mc/mc.ext.
As a quick workaround, you can change one line in your mc.ext:
mc.ext
i/^zip\archiveBranch: 4180_mc.ext_zip_regex
changeset:7881ed2fda7390d3821abd6864d0097fc818f0ac