mc 4.8.26: cannot view content of .xpi archives (firefox extensions, aka zip files with .xpi extension)

[gv]

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)

[andrew_b]

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

@@ -751 +751 @@
        View=%view{ascii} /usr/libexec/mc/ext.d/archive.sh view zip
 
 # zip
-type/i/^zip\ archive
+type/\(Zip archive
        Open=%cd %p/uzip://
        View=%view{ascii} /usr/libexec/mc/ext.d/archive.sh view zip

Branch: 4180_mc.ext_zip_regex
changeset:7881ed2fda7390d3821abd6864d0097fc818f0ac

[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.

[andrew_b]

Sorry, I cannot reproduce that. Please check your files again.

[gv]

I did not quit mc after I changed mc.ext. It works fine now.

Thank you.

[andrew_b]

Ticket #4183 has been marked as a duplicate of this ticket.

[andrew_b]

Merged to master: [a75071b3c07d7dc2795ad2c321e1e340eceadb24].

[alpir]

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.

[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.

[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.

[andrew_b]

Branch: 4180_file_S
changeset:e43c9e6431fe21110097a63cd3f1fd1b35e6353e

[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.

[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).

[andrew_b]

[ec1938db8ef8171440e1a56aea94feec59d23f71]

If file doesn't accept the -z options, it unused at all.

[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.

[andrew_b]

Ticket #4208 has been marked as a duplicate of this ticket.

[andrew_b]

Merged to master: [c9cf22d458709dad97cd2b6cacd61db66178e381].

[gv]

It's still not 100% fiexed.

$ 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 ###" before "### Images ###" fix the above problem.

[andrew_b]

Branch: 4180_mc.ext_archives
changeset:c3848a689c0323ba7958e2943878fe831369af01

[gv]

Works fine. Thank you.

[andrew_b]

Merged to master: [fa2cbd2a2c7e38ee56d1756eac5899b57f7f4262].

[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.

[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

[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?

[andrew_b]

Replying to teras:

Any clues?

Probably #4502.