[Python-Dev] Problems with zipfile.py

[Fred L. Drake, Jr.]

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