Troubles with internal ZIP Plugin

Discussion of bugs and problems found in Altap Salamander. In your reports, please be as descriptive as possible, and report one incident per report. Do not post crash reports here, send us the generated bug report by email instead, please.
User avatar
tukanos
Posts: 410
Joined: 21 Dec 2005, 19:14

Re: Troubles with internal ZIP Plugin

Post by tukanos »

With the 1.zip you are hitting the PATH_LIMIT of windows. The AS developers are trying to cope with it e.g. viewtopic.php?f=2&t=9078 , viewtopic.php?t=32671 , viewtopic.php?f=2&t=9078&p=56771&hilit=long+path#p56771

Thus the internal zip plugin won't work for now, till the AS supports long path (same probably goes for 7zip).

The only way you can extract your file is having an external unzip utility and do the following:

Code: Select all

unzip 1.zip -d \\?\c:\<path>
You have to use the *Unicode* extension "\\?\", which allows you to use maximum path with 32,767 characters.

If you want to read the complexities I suggest reading the https://msdn.microsoft.com/en-us/librar ... s.85).aspx
User avatar
tukanos
Posts: 410
Joined: 21 Dec 2005, 19:14

Re: Troubles with internal ZIP Plugin

Post by tukanos »

10x for the info but the zip filename is pretty short -- 1.zip -- it's the zip contents that is causing troubles with the ZIP Plugin.
I was talking all the time about the content, even thou, not explicitly written.
For instance the ZIP Plugin (and 7-zip) takes care of illegal characters in filenames in the zip contents (e.g. ':', slashes, quotes are converted to '_') but apparently filename length is not taken care when sanitizing archive filenames.
Well that was what I was talking about. AS does not have this support so it does not check the maximum length of 260 characters (you can use I think only 255 to be exact). What happens when you try to click (unpack it) on it; AS tries to open your 1.zip file. ITt tries to extract it to temporary path (which is then displayed in panel as zip content) thus exceeding 260 characters => therefore you see the error.
Most unzip utilities have the same flaw, even 7-zip fails to extract filenames longer than MAX_PATH on Windows (and my vbzip.exe effort is included in the pack).
Well that is called "long path" (or unicode path) support and most of the utilities do not have it. Perhaps you could extract it using PowerShell and the Unicode path too. Thank you for sharing your code!
I'm just sharing these sample zips for testing as I already found a way to extract the contents.
That is good.
User avatar
tukanos
Posts: 410
Joined: 21 Dec 2005, 19:14

Re: Troubles with internal ZIP Plugin

Post by tukanos »

wqweto wrote: 26 Feb 2018, 13:57
tukanos wrote: 26 Feb 2018, 13:41ITt tries to extract it to temporary path (which is then displayed in panel as zip content) thus exceeding 260 characters => therefore you see the error.
Doen't make sense to me, because that would be one very poor implementation of "list archive files" function as you don't need to extract/decompress anything to view zip's central directory and I'm pretty sure AS is not doing any of this.

Dealing with *fixed*-size strings for the AS pane is more plausible explanation. But then hardcoded MAX_PATH check and explicit error returned looks most likey what's happening (probably not in the ZIP plugin but the hosting AS window) and now this would be very unfortunate.

On a side-note: F5 (copy) from zip archive does not allow specifying target filename, bombs with

Code: Select all

---------------------------
Copy Error
---------------------------
Operation masks are not supported when unpacking from archives (target path must exist or end on backslash).
---------------------------
[OK]
---------------------------
. . . so I would be unable to do anything meaningful with such archive contents anyway.

cheers,
</wqw>
As I did not see the code all is speculation. In my opinion, I'm trying to say similar thing as you do but with different wording.
hard-coded MAX_PATH check and explicit error returned looks most likely what's happening
That is, indeed, the most probable cause. Which is what I tried to say when typing "tries to extract it to temporary path" (In my eyes, there is no actual extraction occurring (it is only tries to do so)). During this action it hits the MAX_PATH limit as you have mentioned and you get a generic error message.
(probably not in the ZIP plugin but the hosting AS window)
In the end, it is not important where the error occurs. It can be one or both of these. If there is a hard-limit for the hosting AS window, that would be actually quite good as if the AS developers fix long path in AS, then the zip plugin should start working right after.
Post Reply