Author tadek
Recipients tadek
Date 2008-05-13.22:16:17
SpamBayes Score 1.67214e-06
Marked as misclassified No
Message-id <>
There are cases when gzip produces/receives a zero-padded output, for
example when creating a compressed tar archive with a pipe:

tar cz /dev/null > foo.tgz

ls -la foo.tgz
-rw-r----- 1 tadek tadek 10240 May 13 23:40 foo.tgz

tar tvfz foo.tgz
crw-rw-rw- root/root       1,3 2007-10-18 18:27:25 dev/null

This is a known behavior ( and recent versions
of gzip handle it gracefully by skipping all zero bytes after the end of
the file (see gzip.c:1394-1406 in the version 1.3.12).

The Python gzip module crashes on those files:

#:~/python2.5/py2.5$ tar cz /dev/null > foo.tgz
tar: Removing leading `/' from member names
#:~/python2.5/py2.5$ bin/python
Python 2.5.2 (r252:60911, May 14 2008, 00:02:24)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gzip
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/tadek/python2.5/py2.5/lib/python2.5/", line 220, in
  File "/home/tadek/python2.5/py2.5/lib/python2.5/", line 263, in
  File "/home/tadek/python2.5/py2.5/lib/python2.5/", line 164, in
    raise IOError, 'Not a gzipped file'
IOError: Not a gzipped file

The proposed patch fixes this behavior by reading all zero characters at
the end of the file. I tested that it works with: regular archives,
zero-padded archives, concatenated archives and concatenated zero-padded

Date User Action Args
2008-05-13 22:16:26tadeksetspambayes_score: 1.67214e-06 -> 1.67214e-06
recipients: + tadek
2008-05-13 22:16:23tadeksetspambayes_score: 1.67214e-06 -> 1.67214e-06
messageid: <>
2008-05-13 22:16:22tadeklinkissue2846 messages
2008-05-13 22:16:21tadekcreate