diff options
| author | Tim Peters <tim.peters@gmail.com> | 2002-11-05 20:38:55 (GMT) |
|---|---|---|
| committer | Tim Peters <tim.peters@gmail.com> | 2002-11-05 20:38:55 (GMT) |
| commit | 9288f95cb5d7be807c2ba6dbc195ec6b52ac3bd4 (patch) | |
| tree | 7d5a21cd8f3f32e6eb093e4399de65d2df4a157e /Misc | |
| parent | cd8fdbb3fad7f81a84507d2294613016fccd0954 (diff) | |
| download | cpython-9288f95cb5d7be807c2ba6dbc195ec6b52ac3bd4.zip cpython-9288f95cb5d7be807c2ba6dbc195ec6b52ac3bd4.tar.gz cpython-9288f95cb5d7be807c2ba6dbc195ec6b52ac3bd4.tar.bz2 | |
Another round on SF patch 618135: gzip.py and files > 2G
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.
Diffstat (limited to 'Misc')
| -rw-r--r-- | Misc/NEWS | 9 |
1 files changed, 6 insertions, 3 deletions
@@ -355,9 +355,12 @@ Extension modules Library ------- -- gzip.py now handles files exceeding 2GB. Note that 4GB is still a - fundamental limitation of the underlying gzip file format (it only - has 32 bits to record the file size). +- gzip.py now handles files exceeding 2GB. Files over 4GB also work + now (provided the OS supports it, and Python is configured with large + file support), but in that case the underlying gzip file format can + record only the least-significant 32 bits of the file size, so that + some tools working with gzipped files may report an incorrect file + size. - xml.sax.saxutils.unescape has been added, to replace entity references with their entity value. |