Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Problems viewing zip files #4368

Closed
mc-butler opened this issue Apr 17, 2022 · 19 comments
Closed

Problems viewing zip files #4368

mc-butler opened this issue Apr 17, 2022 · 19 comments
Labels
area: core Issues not related to a specific subsystem prio: medium Has the potential to affect progress
Milestone
4.8.29

Comments

@mc-butler
Copy link

Important

This issue was migrated from Trac:

Origin https://midnight-commander.org/ticket/4368
Reporter blacktav (blacktav@….com)

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'

Note

Original attachments:
@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Apr 17, 2022 at 15:09 UTC (comment 1)

  • Status changed from new to closed
  • Resolution set to invalid
  • Milestone Future Releases deleted

There was some changes in mc.ext file. You should sync your user's mc.ext with system-wide one.

See also #4180 comment 22.

@mc-butler
Copy link
Author

Changed by blacktav (blacktav@….com) on Apr 22, 2022 at 10:51 UTC (comment 2)

  • Status changed from closed to reopened
  • Resolution invalid deleted

Sorry, but the fix mentioned in #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?

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Apr 22, 2022 at 11:55 UTC (comment 3)

Do you have ~/.config/mc/mc.ext? If yes, are ~/.config/mc/mc.ext and /etc/mc/mc.ext different?

@mc-butler
Copy link
Author

Changed by blacktav (blacktav@….com) on Apr 22, 2022 at 12:35 UTC (comment 4)

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

@mc-butler
Copy link
Author

Changed by blacktav (blacktav@….com) on Apr 22, 2022 at 12:37 UTC (comment 5)

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

@mc-butler
Copy link
Author

Changed by blacktav (blacktav@….com) on Apr 22, 2022 at 12:54 UTC

Contains jpg images - fails to open

@mc-butler
Copy link
Author

Changed by blacktav (blacktav@….com) on Apr 22, 2022 at 12:54 UTC

Contains random stuff from mc source code - opens fine in mc

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Apr 23, 2022 at 6:01 UTC (comment 6)

This is the result of #4128 [8857423]. 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 [7881ed2]
#4180 [c3848a6]
#4223 [0e023f0]
#4273 [78f8f97]
#4272 [53b1bb6]

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

@mc-butler
Copy link
Author

Changed by ossi (@ossilator) on Apr 23, 2022 at 9:30 UTC (comment 7)

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.

@mc-butler
Copy link
Author

Changed by blacktav (blacktav@….com) on Apr 23, 2022 at 10:02 UTC (comment 8)

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

I can provide a sample file but it is too large (14389K) for this tracker - here is a link

# 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

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Apr 23, 2022 at 10:59 UTC (comment 8.9)

Replying to 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 [1ed638d].

@mc-butler
Copy link
Author

Changed by blacktav (blacktav@….com) on Apr 23, 2022 at 11:11 UTC (comment 9.10)

Replying to andrew_b:

Replying to 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 [1ed638d].

Ahhh - Good call!

@mc-butler
Copy link
Author

Changed by ossi (@ossilator) on Apr 23, 2022 at 16:50 UTC (comment 11)

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.

@mc-butler
Copy link
Author

Changed by blacktav (blacktav@….com) on Apr 23, 2022 at 17:45 UTC (comment 11.12)

Replying to 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

@mc-butler
Copy link
Author

Changed by ossi (@ossilator) on Apr 23, 2022 at 17:55 UTC (comment 13)

see discussion in #2118.

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Jul 11, 2022 at 16:39 UTC (comment 14)

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

@mc-butler
Copy link
Author

Changed by ulno (devel@….ulno.net) on Aug 6, 2022 at 14:50 UTC (comment 15)

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

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Aug 24, 2022 at 9:53 UTC (comment 16)

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

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Sep 25, 2022 at 12:16 UTC (comment 17)

  • Milestone set to 4.8.29
  • Resolution set to fixed
  • Status changed from reopened to closed

I hope this is finally fixed in #4141.

@mc-butler mc-butler marked this as a duplicate of #4403 Feb 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area: core Issues not related to a specific subsystem prio: medium Has the potential to affect progress
Milestone
4.8.29
Development

No branches or pull requests
1 participant
@mc-butler