svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r85291 | antoine.pitrou | 2010-10-06 23:21:18 +0200 (mer., 06 oct. 2010) | 4 lines
Issue #9759: GzipFile now raises ValueError when an operation is attempted
after the file is closed. Patch by Jeffrey Finkelstein.
........
read 32bit values as unsigned to start with rather than applying signedness
fixups allover the place afterwards.
This hopefully fixes the test_tarfile failure on the alpha/tru64 buildbot.
buildbot (& possibly other 64-bit boxes) during test_gzip.
The native zlib crc32 function returns an unsigned 32-bit integer,
which the Python wrapper implicitly casts to C long. Therefore the
same crc can "look negative" on a 32-bit box but "look positive" on
a 64-bit box. This patch papers over that platform difference when
writing the crc to file.
It may be better to change the Python wrapper, either to make
the result "look positive" on all platforms (which means it may
have to return a Python long at times on a 32-bit box), or to
keep the sign the same across boxes. But that would be a visible
change in what users see, while the current hack changes no
visible behavior (well, apart from stopping the struct deprecation
warning).
Note that the module-level write32() function is no longer used.
gzip shouldn't raise ValueError on corrupt files
Currently the gzip module will raise a ValueError if the file was
corrupt (bad crc or bad size). I can't see how that applies to
reading a corrupt file. IOError seems better, and it's what code
will likely be looking for.
The last round boosted "the limit" from 2GB to 4GB. This round gets
rid of the 4GB limit. For files > 4GB, gzip stores just the last 32
bits of the file size, and now we play along with that too. Tested
by hand (on a 6+GB file) on Win2K.
Boosting from 2GB to 4GB was arguably enough "a bugfix". Going beyond
that smells more like "new feature" to me.
Fixed the signed/unsigned confusions when dealing with files >= 2GB.
4GB is still a hard limitation of the gzip file format, though.
Testing this was a bitch on Win98SE due to frequent system freezes. It
didn't freeze while running gzip, it kept freezing while trying to *create*
a > 2GB test file! This wasn't Python's doing. I don't know of a
reasonable way to test this functionality in regrtest.py, so I'm not
checking in a test case (a test case would necessarily require creating
a 2GB+ file first, using gzip to zip it, using gzip to unzip it again,
and then compare before-and-after; so >4GB free space would be required,
and a loooong time; I did all this "by hand" once).
Bugfix candidate, I guess.
Nadeem Vawda
Antoine Pitrou
Mark Dickinson
Lars Gustäbel
Philip Jenvey
Georg Brandl
Gregory P. Smith
Martin v. Löwis
Tim Peters
Bob Ippolito
Andrew M. Kuchling
Walter Dörwald
Brett Cannon
Guido van Rossum
Raymond Hettinger
Skip Montanaro
Neil Schemenauer
Fred Drake
Jack Jansen
Eric S. Raymond
Jeremy Hylton