ZTree.com  | ZEN  | About...  

 Index   Back

[Bug] Info-ZIP DLLs   [Bug]

By: John Gruener     Orlando, Florida  
Date: Aug 26,2019 at 18:53
In Response to: [Bug] Hello all. re: pkzipc not decrypting a zip file created in pkzip for windows 14 (Paul Borisoff)

> A bug? This is not a big issue, but it will be nice to see the root
> of the problem.
> A zip file created using ctrl-F5 and invoking pkzipc (through
> archiver.bb2) can be decrypted using alt-F5... put in the password and it
> extracts.
> A zip file created and encrypted by pkzip for windows 14 (the mother
> program)can not be decrypted by the command-line, pkzipc using alt-F5.
> Ztree returns error [81] uncompatible format.
> Yet... executing pkzipc as a stand-alone from the run prompt of windows
> 10 or from ztree's command-line (x) works fine. pkzip for windows can
> handle the encrypted file produced by ztree.
> I am using the profile for pkzip 4.x/5.0 listed in the archiver.bb2 It
> invokes pkzipc and I presume that the commands listed haven't changed.
> The pkzip.exe is only present on the system once and accompanies the
> current verson. I added its location to the environmental path.
> So obviously the answer is to encrypt and decrypt within the same
> program. But I'm curious why decryption fails when using alt-F5,
> invoking pkzipc.

It may have nothing to do with decryption. Did you try this without encryption? It may be because ZTree is internally using the Info-ZIP DLLs when you run it from ZTree, and these DLLs are not used when you run it from the command line. Are these DLL files present in your ZTree directory?

If the UNZIP32/64.DLL files exist in your ZTree directory, then I believe it's because ZTree is not actually using PKZIPC. If they don't exist, then I'm not sure why PKZIPC would work from the command line but not from ZTree using the PKZIPC BB2 entry.

I see a similar problem when the DLLs are present. I do not have a copy of PKZIP for Windows v14, so am unable to duplicate the [81] error message you are seeing. I am also not working with a password-encrypted ZIP file. So it's possible that there is more than one issue at play. What is clear however is that some ZIP files, having the same "PK\x3\x4" signature, are in fact compressed differently.

My issue is based on attempts to extract the Process Hacker nightly builds downloaded from:
Martijn Coppoolse and Ron Metzger mentioned using it in this thread:
I've been using v3 for more than a year, occasionally downloading newer builds.

So based on running tests with this file (and not any knowledge of ZTree internal code) here's what I think is happening:

For display and navigation within the ZIP file, when ZTree first opens the file it always uses the first entry with the "PK\x3\x4" signature found in the BB2 file. However, although it's displaying the name line of this BB2 entry on the bottom menu line, when Ctrl or Alt are used to Extract tagged files it actually internally uses the Info-ZIP UNZIP32/64.DLL file if it exists in the ZTree directory. Extracting single files works OK, so it appears the DLLs are not used for single-file extracts. (Kim, please correct me if I'm wrong about any of this.)

In the case of this downloaded file, when I use Alt-F5, then Ctrl-Extract or Alt-Extract, I get "Error: Archiver returned [11]". This error only occurs with files in subdirectories. Tagged files in the root of the ZIP extract OK.

To prove it's the DLLs causing the error, rename those DLLs and restart ZTree. The first BB2 entry with the "PK\x3\x4" signature (PKZIPC or other) will then correctly extract all the files. The problem with permanently doing this is you give up the much faster processing on legacy ZIP files when ZTree is internally using the DLLs.

Unfortunately, Info-ZIP has not been updated for over 10 years, and may never be updated. So open source DLLs compatible with some newer compression methods may never be available.

If, in fact, there is no unique signature identifying these newer ZIP files, then one possible fix for this might be for ZTree to internally and silently test for an error (using a subdirectory in the ZIP if one exists). Then if an error occurs, automatically fall back to the BB2 entry. Hopefully the test would not add any noticeable overhead.

- John

Thread locked

Messages in this Thread

95,097 Postings in 11,989 Threads, 350 registered users, 65 users online (0 registered, 65 guests)
Index | Admin contact |   Forum Time: Sep 20, 2020 - 9:48 am EDT  |  Hits:34,154,193  (10,749 Today )
RSS Feed