-
Notifications
You must be signed in to change notification settings - Fork 3
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.
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
Problems viewing zip files #4368
Comments
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? |
Do you have ~/.config/mc/mc.ext? If yes, are ~/.config/mc/mc.ext and /etc/mc/mc.ext different? |
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 |
Please note that I am using a download from Google Photo i.e. the zip file contains several jpg files |
Contains jpg images - fails to open |
Contains random stuff from mc source code - opens fine in mc |
This is the result of #4128 [8857423]. The file utility with -z option is used to determinate file type:
After #4128 we made several iterations to fix introduced problems:
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/). |
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.
(*) they can be still entered with ctrl-pgdn if one really wants to.
note also #4141, which is somewhat complementary. |
Why do you want open a zip file containing jpg files when trying to determine if a file is a jpg?
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
|
Replying to andrew_b:
Ahhh - Good call! |
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. |
Replying to ossi:
Interesting! |
see discussion in #2118. |
Ticket #4390 has been marked as a duplicate of this ticket. |
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):
|
Important
This issue was migrated from Trac:
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
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)
Note
Original attachments:
blacktav
(blacktav@….com) onApr 22, 2022 at 12:54 UTC
blacktav
(blacktav@….com) onApr 22, 2022 at 12:54 UTC
The text was updated successfully, but these errors were encountered: