James C. Ahlstrom writes: > It turns out that InfoZip's Wiz version 5.02 (and maybe other > InfoZip versions) creates ZIP files with an incorrect value > for "extra data length" in the central directory, but the correct > value in the file header. The "extra data" is before the compressed > file data, and so this causes the file data offset to be off slightly > thus causing complaints from the zlib decompressor. I changed > zipfile.py to use the file header value, and it fixes the problem. This was fixed by a patch from Jens Quade in CVS revision 1.7 of zipfile.py. > I also added a new method restore(self, name, fileobject) which > was suggested some time ago by MAL. It writes to an open file > or any other object with a write() method. It avoids the need > to read the whole file into memory. Cool! I'll try to look at this Monday, but I'm not sure it should go in for Python 2.1 -- it is a new feature, and we're supposed to be in a feature freeze. > I also changed the "raise" statements to use the "zipfile.error" > exception. This agrees with the documentation, but previously > zipfile raised a variety of exceptions. This also fixes the > complaint that "BadZipfile" should be spelled "BadZipFile". I think the exceptions situation has been cleaned up as well. You might want to take a look at the version in Python CVS (soon to be Python 2.1) to see what else has changed (most substantially, Itamar Shtull-Trauring added support for loading ZIP files from open file objects). -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4