This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author martin.panter
Recipients martin.panter
Date 2014-01-13.10:24:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1389608683.35.0.244495356969.issue20238@psf.upfronthosting.co.za>
In-reply-to
Content
I am trying to create a tar file after opening it as a temporary file, and it seems to be writing truncated output when I use mode="w:gz". My workaround looks like it will be to use mode="w|gz" instead. It’s not clear what the difference is: am I losing anything practical by disallowing “random” seeking?

Simplified demonstration:

>>> from io import BytesIO; b = BytesIO()
>>> import tarfile; t = tarfile.open(fileobj=b, mode="w:gz")
>>> t._extfileobj
True
>>> type(t.fileobj)
<class 'gzip.GzipFile'>
>>> t.close()
>>> b.getvalue()
b'\x1f\x8b\x08\x00]\xb8\xd3R\x02\xff'
>>> del t
>>> b.getvalue()
b"\x1f\x8b\x08\x00]\xb8\xd3R\x02\xff\xed\xc1\x01\r\x00\x00\x00\xc2\xa0\xf7Om\x0e7\xa0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x807\x03\x9a\xde\x1d'\x00(\x00\x00"

Looking at the code, the TarFile.close() method would not be closing the GzipFile object because of this condition:

if not self._extfileobj:
    self.fileobj.close()

Perhaps it needs to also check if file compression is being used or something; I’m not familiar with the internals.

I did notice that the bug happens with Python 3.3.3 and 3.2.3, but not 2.7.5. Also, I do not see the issue when a file name is passed to tarfile.open() rather than a file object, nor do I see it with the bzip or XZ compressors, uncompressed tar creation, or the “special purposes” w|gz mode.
History
Date User Action Args
2014-01-13 10:24:43martin.pantersetrecipients: + martin.panter
2014-01-13 10:24:43martin.pantersetmessageid: <1389608683.35.0.244495356969.issue20238@psf.upfronthosting.co.za>
2014-01-13 10:24:43martin.panterlinkissue20238 messages
2014-01-13 10:24:42martin.pantercreate