Ticket #4180 (closed defect: fixed)

Opened 4 years ago

Last modified 15 months ago

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

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

    old new  
    751751       View=%view{ascii} /usr/libexec/mc/ext.d/archive.sh view zip 
    752752 
    753753# zip 
    754 type/i/^zip\ archive 
     754type/\(Zip archive 
    755755       Open=%cd %p/uzip:// 
    756756       View=%view{ascii} /usr/libexec/mc/ext.d/archive.sh view zip 

Branch: 4180_mc.ext_zip_regex
changeset:7881ed2fda7390d3821abd6864d0097fc818f0ac

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

comment:8 Changed 4 years ago by andrew_b

  • Status changed from testing to closed

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:10 Changed 4 years ago by alpir

  • Cc jg.staffel@… added

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:13 Changed 4 years ago by onlyjob

  • Cc onlyjob@… added

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

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

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.

Last edited 4 years ago by gv (previous) (diff)

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

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

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

comment:30 in reply to: ↑ 29 Changed 15 months ago by andrew_b

Replying to teras:

Any clues?

Probably #4502.

Note: See TracTickets for help on using tickets.