[Midnight Commander] #4368: Problems viewing zip files
Ticket System
--------------------------------+-------------------------------
Reporter: blacktav | Type: defect
Status: new | Priority: major
Milestone: Future Releases | Component: mc-core
Version: master | Keywords:
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
--------------------------------+-------------------------------
I am experiencing strange behaviour with some zip files
== a zip file built locally using zip 3.0 ==
In mc this behaves as expected: `view` opens a file list, `open` permits
browsing the contents of the zip file (ie. using extfs uzip)
File type reported as
{{{
Kerryvanning.zip: Zip archive data, at least v1.0 to extract, compression
method=store
}}}
== a download from Google's photo tool ==
`view`::
mc throws an error
{{{identify: no decode delegate for the image format `ZIP' @
error/constiture.c/ReadImage/737.}}}
`open`::
mc opens the file for browsing but in an external app triggering a call
through xdg
File type is reported as:
{{{Photos-2016.zip: Zip archive data, at least v2.0 to extract,
compression method=deflate}}}
== mc.ext ==
There are 2 definitions for zip files: one on the file extension
{{{shell/i/.zip}}}, the other by type {{{type/\(Zip archive}}} although
they both have the same commands and it does not matter which is triggered
- behaviour is identical
ie. I removed one or other or both
== Conclusion & workaround ==
Given the `view` error message, it looks like the file is being
interpreted as an `image` and handed off as appropriate
Commenting out the image type handlers in mc.ext (the JPG one in
particular) and behaviour reverts to normal zip-file handling.
workaround::
Since the image types appear before compressed file detection, moving
image detection to later in the `mc.ext` file produces normal behaviour
There must be some issue with the built-in file-type detection (the tested
file does contain JPG images)
----
{{{
Home directory: /home/drew
Profile root directory: /home/drew
[System data]
Config directory: /etc/mc/
Data directory: /usr/share/mc/
File extension handlers: /usr/lib/mc/ext.d/
VFS plugins and scripts: /usr/lib/mc/
extfs.d: /usr/lib/mc/extfs.d/
fish: /usr/lib/mc/fish/
[User data]
Config directory: /home/drew/.config/mc/
Data directory: /home/drew/.local/share/mc/
skins: /home/drew/.local/share/mc/skins/
extfs.d: /home/drew/.local/share/mc/extfs.d/
fish: /home/drew/.local/share/mc/fish/
mcedit macros: /home/drew/.local/share/mc/mc.macros
mcedit external macros:
/home/drew/.local/share/mc/mcedit/macros.d/macro.*
Cache directory: /home/drew/.cache/mc/
'--prefix=/usr' '--libexecdir=/usr/lib' '--sysconfdir=/etc' '--enable-
vfs-smb' '--with-screen=slang' '--with-x' 'CFLAGS=-march=x86-64
-mtune=generic -O2 -pipe -fno-plt -fexceptions
-Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-
clash-protection -fcf-protection -flto=auto' 'LDFLAGS=-Wl,-O1,--sort-
common,--as-needed,-z,relro,-z,now -flto=auto'
}}}
--
Ticket URL: <http://www.midnight-commander.org/ticket/4368>
Midnight Commander <https://midnight-commander.org>
Midnight Development Center
Ticket System
Reporter: blacktav | Owner:
Type: defect | Status: closed
Priority: major | Milestone:
Component: mc-core | Version: master
Resolution: invalid | Keywords:
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Changes (by andrew_b):
* status: new => closed
* resolution: => invalid
* milestone: Future Releases =>
Comment:
There was some changes in mc.ext file. You should sync your user's mc.ext
with system-wide one.
See also ticket:4180#comment:22.
--
Ticket URL: <http://www.midnight-commander.org/ticket/4368#comment:1>
Ticket System
Reporter: blacktav | Owner:
Type: defect | Status: reopened
Priority: major | Milestone:
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Changes (by blacktav):
* status: closed => reopened
* resolution: invalid =>
Comment:
Sorry, but the fix mentioned in ticket:4180#comment:22 has not been
actioned - misc/mc.ext.in does not include such a change in the current
source tree i.e. "### Images ###" still precedes compressed file
definitions
Builds for 4.8.28 continue to generate a broken mc.ext file
Perhaps a recent change reverted a fix? Or have I missed something?
--
Ticket URL: <http://www.midnight-commander.org/ticket/4368#comment:2>
Ticket System
Reporter: blacktav | Owner:
Type: defect | Status: reopened
Priority: major | Milestone:
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by andrew_b):
Do you have `~/.config/mc/mc.ext`? If yes, are `~/.config/mc/mc.ext` and
`/etc/mc/mc.ext` different?
--
Ticket URL: <http://www.midnight-commander.org/ticket/4368#comment:3>
Ticket System
Reporter: blacktav | Owner:
Type: defect | Status: reopened
Priority: major | Milestone:
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by blacktav):
No - I have no local mc.ext
I have edited my system mc.ext so that '## Images ##' follows compressed
files. This opens zip files for browsing as expected
If I build mc 4.8.28 from a source download and copy the mc.ext created
into my local config i.e. to .config/mc and restart mc - then opening zip
files fail
--
Ticket URL: <http://www.midnight-commander.org/ticket/4368#comment:4>
Ticket System
Reporter: blacktav | Owner:
Type: defect | Status: reopened
Priority: major | Milestone:
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by blacktav):
Please note that I am using a download from Google Photo i.e. the zip file
contains several jpg files
Hold on and I will upload a test file for you...
--
Ticket URL: <http://www.midnight-commander.org/ticket/4368#comment:5>
Ticket System
Reporter: blacktav | Owner:
Type: defect | Status: reopened
Priority: major | Milestone:
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by andrew_b):
This is the result of #4128 [8857423e4ebb770b6f0ea3103abf5d35c85fcbe8].
The `file` utility with `-z` option is used to determinate file type:
{{{
$ file -L mc-test-fail.zip
mc-test-fail.zip: Zip archive data, at least v2.0 to extract
$ file -z -L mc-test-fail.zip
mc-test-fail.zip: JPEG image data, JFIF standard 1.01 (Zip archive data,
at least v2.0 to extract)
}}}
After #4128 we made several iterations to fix introduced problems:
#4180 [7881ed2fda7390d3821abd6864d0097fc818f0ac]
#4180 [c3848a689c0323ba7958e2943878fe831369af01]
#4223 [0e023f0dd9ca18a2bab8df6d25ed3c7d9dcbd2d1]
#4273 [78f8f97fed3a478e20e4a78297f73b0f84f697a9]
#4272 [53b1bb63acaa93a1c41a22a5c6ac1204b6140aed]
The new attempt is yet another change of rules order: first view at file
names (`regex/` and `shell/`), than file types detected by `file -z -L`
(`type/`).
--
Ticket URL: <http://www.midnight-commander.org/ticket/4368#comment:6>
Ticket System
Reporter: blacktav | Owner:
Type: defect | Status: reopened
Priority: major | Milestone:
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by ossi):
> first view at file names (regex/ and shell/), than file types detected
by file -z -L (type/).
not necessarily.
first one needs to match things that are technically archives, but aren't
supposed to be treated as such (*), e.g. various ODF files, and compressed
man pages.
then one can match "regular" archives.
this can all be done by type, though matching by patterns is of course
more efficient (but requires them to be truly unique, and no weird
alternative file names being used).
then match everything else, which will be never reached if the file is
inside an archive.
(*) they can be still entered with ctrl-pgdn if one really wants to.
note also #4141, which is somewhat complementary.
--
Ticket URL: <http://www.midnight-commander.org/ticket/4368#comment:7>
Ticket System
Reporter: blacktav | Owner:
Type: defect | Status: reopened
Priority: major | Milestone:
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by blacktav):
Why do you want open a zip file containing jpg files when trying to
determine if a file is a jpg?
Are you expecting to be able to render all jpgs within a zip container?
Anyways the file "-z" switch may be problematic: when used against some
files (the files I am having a problem with), it crashes
{{{
# file --version
file-5.41
magic file from /usr/share/file/misc/magic
seccomp support included
# file Photos-2021.zip
Photos-2021.zip: Zip archive data, at least v2.0 to extract, compression
method=deflate
# file -z Photos-2021.zip
Photos-2021.zip: Bad system call
}}}
--
Ticket URL: <http://www.midnight-commander.org/ticket/4368#comment:8>
Ticket System
Reporter: blacktav | Owner:
Type: defect | Status: reopened
Priority: major | Milestone:
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by andrew_b):
Replying to [comment:8 blacktav]:
> Anyways the file "-z" switch may be problematic: when used against some
files (the files I am having a problem with), it crashes
This is known issue and it was fixed in
[1ed638d66cf803f69ac12ee80a72d217f2146e43].
--
Ticket URL: <http://www.midnight-commander.org/ticket/4368#comment:9>
Ticket System
Reporter: blacktav | Owner:
Type: defect | Status: reopened
Priority: major | Milestone:
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by blacktav):
Replying to [comment:9 andrew_b]:
> Replying to [comment:8 blacktav]:
> > Anyways the file "-z" switch may be problematic: when used against
some files (the files I am having a problem with), it crashes
>
> This is known issue and it was fixed in
[1ed638d66cf803f69ac12ee80a72d217f2146e43].
Ahhh - Good call!
--
Ticket URL: <http://www.midnight-commander.org/ticket/4368#comment:10>
Ticket System
Reporter: blacktav | Owner:
Type: defect | Status: reopened
Priority: major | Milestone:
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by ossi):
> Why do you want open a zip file containing jpg files when trying to
determine if a file is a jpg?
nobody ''wants'' that per se. a hierarchical decision tree that uses file
-z only in some branches would be better, but it would require more
complicated infrastructure.
i actually find it kinda weird that `file -z` describes the contents of
multi-file archives without specific semantics. but it is what it is.
--
Ticket URL: <http://www.midnight-commander.org/ticket/4368#comment:11>
Ticket System
Reporter: blacktav | Owner:
Type: defect | Status: reopened
Priority: major | Milestone:
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by blacktav):
Replying to [comment:11 ossi]:
> > Why do you want open a zip file containing jpg files when trying to
determine if a file is a jpg?
>
> nobody ''wants'' that per se. a hierarchical decision tree that uses
file -z only in some branches would be better, but it would require more
complicated infrastructure.
>
> i actually find it kinda weird that `file -z` describes the contents of
multi-file archives without specific semantics. but it is what it is.
Interesting!
Would a mime-type detector work in this case? i.e. would a mime-type be
sufficiently granular for {{{mc}}} purposes?
I am rather surprised that there does not appear to be any such linux/gnu
tool
--
Ticket URL: <http://www.midnight-commander.org/ticket/4368#comment:12>
Ticket System
Reporter: blacktav | Owner:
Type: defect | Status: reopened
Priority: major | Milestone:
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by ossi):
see discussion in #2118.
--
Ticket URL: <http://www.midnight-commander.org/ticket/4368#comment:13>
Ticket System
Reporter: blacktav | Owner:
Type: defect | Status: reopened
Priority: major | Milestone:
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by andrew_b):
Ticket #4390 has been marked as a duplicate of this ticket.
--
Ticket URL: <http://www.midnight-commander.org/ticket/4368#comment:14>
Ticket System
Reporter: blacktav | Owner:
Type: defect | Status: reopened
Priority: major | Milestone:
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by ulno):
As it still doesn't seem to be fixed upstream and to give others a chance
to use the old mc behavior (just broke a 20 year old workflow for me), I
added these lines to the beginning of ### Archives ### section in mc.ext
(for me in Arch with either mc-git or mc 4.8.28 under /etc/mc/mc.ext - or
of course just inside your home .config/mc):
{{{
regex/\.[zZ][iI][pP]$
Open=%cd %p/uzip://
View=%view{ascii} /usr/lib/mc/ext.d/archive.sh view zip
}}}
--
Ticket URL: <http://www.midnight-commander.org/ticket/4368#comment:15>
Ticket System
Reporter: blacktav | Owner:
Type: defect | Status: reopened
Priority: major | Milestone:
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by andrew_b):
Ticket #4403 has been marked as a duplicate of this ticket.
--
Ticket URL: <http://www.midnight-commander.org/ticket/4368#comment:16>
Ticket System
Reporter: blacktav | Owner:
Type: defect | Status: closed
Priority: major | Milestone: 4.8.29
Component: mc-core | Version: master
Resolution: fixed | Keywords:
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Changes (by andrew_b):
* status: reopened => closed
* resolution: => fixed
* milestone: => 4.8.29
Comment:
I hope this is finally fixed in #4141.
--
Ticket URL: <http://www.midnight-commander.org/ticket/4368#comment:17>