In the comments of the last blog post about encrypted zip files several people encountered problems with zip files encrypted with the shown sources. Well, I have to apologize: this actually cannot work with the sources provided due to some suboptimal behavior of TZipFile. Its current implementation calculates the CRC32 value after encrypting the data. For that the CRC32 value used for encryption is simply incorrect.
The reason why this slipped through is damn simple: As my first approach was implementing this feature in the original sources, I changed this right in the beginning and later forgot about it completely when moving this feature into a derived class. Thus my tests succeeded just because they still used the manipulated version of System.Zip.
It turned out that getting the correct CRC32 value for encryption without changing the original source was anything but easy. For the sake of providing at least one solution in a timely manner, I opted for sacrificing performance and memory considerations, which can surely be optimized in a later approach. As a benefit the current solution also closes a memory leak present in the previous version.
The new version can be downloaded here:
The first part of this article describes a simple but limited way to read password encrypted zip files with a derived TZipFile class. The limitations are
- it can only read but not create encrypted zip files
- the size of the zip files is limited by the available memory
While this solution does the job in the scenario it was built for, I cannot say that I was really satisfied with that. So I investigated ways how these limitations can be overcome.
It turned out that it was not that easy as I anticipated. Continue reading
As some of you might already know, Delphi (at least since XE2) comes with a built-in TZipFile class for reading and writing zip files. It is a rather basic class with only limited functionality, but this might just be enough for quite a couple of day-to-day tasks.
During a recent migration of a project from Delphi 7 to Delphi 10.1 Berlin I was facing the decision to either fix the current zip implementation (based on external DLLs) or switch to the stock implementation using TZipFile. The second option would also have the advantage of getting rid of distributing the DLLs. So I headed for that one.
Well, as always when you think you have found the right solution and start coding – reality steps in. Some of the zip files we had to read were password protected. Unfortunately TZipFile doesn’t support password encryption out of the box. Continue reading
I have uploaded some updates for my IDE plugins, mostly only to support Delphi 10.2 Tokyo.
SelectiveDebugging only got Tokyo support while support for XE is dropped.
PackageMagician got Tokyo support and some enhancements:
- Packages can be given with relative paths to the project
- The path of any loaded package is added to the PATH environment variable
DprojNormalizer also got Tokyo support. In addition some more entries are normalized. A command line utility completes this version allowing batch normalizing of dproj files.
I am not sure if normalizing is still necessary as Tokyo fixes bug RSP-11308: Inconsistent sort order in dproj files causes havoc with version control systems.
Update: There seem to be some intermittent problems with PackageMagician when unloading a package. Although it seems that Delphi actually unloads that package it refuses to load another package with the same name. This might be related to the package cache, but I haven’t found a solution for that yet.
A couple of years ago I wrote a two-part article about a dataset enumerator: A Magical Gathering – Part 1 and Part 2. Well, things evolved a bit since then and I wondered how one would implement something similar given the current features of Delphi. Actually I am following here a suggestion from commenter Alan Clark. Continue reading