svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r84737 | antoine.pitrou | 2010-09-12 16:51:20 +0200 (dim., 12 sept. 2010) | 4 lines
Issue #9837: The read() method of ZipExtFile objects (as returned by
ZipFile.open()) could return more bytes than requested.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r83959 | antoine.pitrou | 2010-08-12 17:11:50 +0200 (jeu., 12 août 2010) | 5 lines
Issue #7467: when a file from a ZIP archive, its CRC is checked and a
BadZipfile error is raised if it doesn't match (as used to be the
case in Python 2.5 and earlier).
........
r83960 | antoine.pitrou | 2010-08-12 17:15:01 +0200 (jeu., 12 août 2010) | 3 lines
Typo.
........
:class:`zipfile.ZipExtFile` class used to represent files stored inside
an archive. The new implementation is significantly faster and can
be wrapped in a :class:`io.BufferedReader` object for more speedups.
It also solves an issue where interleaved calls to `read()` and
`readline()` give wrong results. Patch by Nir Aides.
Also fixes
- Issue #1526: Allow more than 64k files to be added to Zip64 file.
- Issue #1746: Correct handling of zipfile archive comments (previously
archives with comments over 4k were flagged as invalid). Allow writing
Zip files with archives by setting the 'comment' attribute of a ZipFile.
type of encrypted zip files. Files using extended local headers
needed to compare the check byte against different values. (according
to reading the infozip unzip crypt.c source code)
Fixes issue1003.
warning on Windows.
Afraid I can't detect a pattern to when the pack formats decide
to use a signed or unsigned format code -- appears nearly
arbitrary to my eyes. So I left all the pack formats alone and
changed the special-case data values instead.
warnings on Win32.
Also added an XXX about the line:
pos3 = self.fp.tell()
`pos3` is never referenced, and I have no idea what the code
intended to do instead.
(ZIP file spec. says in section K, "General notes" in point 1 that unless
specified otherwise values are unsigned and they are not specified as signed in
the spec).
Closes bug #679953. Thanks Jimmy Burgett.
This is a patch for Bug 755031: If a null byte appears in
a file name, Python zipfile.py retains it, but InfoZip
terminates the name. Null bytes in file names are used
as a trick by viruses. I tested WinZip, and it also
truncates the file name at the null byte.
The patch also fixes a buglet: If a zipfile incorrectly
uses a directory separator other than '/', there was an
invalid complaint that the central directory name does
not match the file header name.
I also removed my name from the top of the file. It was
there for legal reasons which I believe no longer apply.
Many people have worked on this file besides me.