classification
Title: Fixing tarfile._mode when using gzip via ":gz"
Type: behavior Stage: patch review
Components: Library (Lib) Versions: Python 3.4
process
Status: open Resolution:
Dependencies: 18321 Superseder:
Assigned To: Nosy List: edulix, jcea, lars.gustaebel, serhiy.storchaka
Priority: normal Keywords: patch

Created on 2013-07-28 08:35 by edulix, last changed 2013-09-20 19:24 by serhiy.storchaka.

Files
File name Uploaded Description Edit
gzip.patch edulix, 2013-07-28 08:39
Messages (3)
msg193812 - (view) Author: Eduardo Robles Elvira (edulix) * Date: 2013-07-28 08:35
A TarFile object constructor accepts a fileobj argument. When this argument is set and it has a "mode" property, tarfile._mode is blindly copied from there. Otherwise, mode is set using the mode argument in the constructor.

This usually works, but in the case where fileobj is a gzip.GzipFile, the "mode" property is not a string like "rb" or "wb" but an integer, which is not expected in TarFile. 

This has not been noticed before probably because the TarFile._mode property is usually unused internally, but in my case it's a problem when using it together with tarfile multivolume mode provided in issue #18321.
msg193813 - (view) Author: Eduardo Robles Elvira (edulix) * Date: 2013-07-28 08:39
Fixing  gzip.patch, it was using basestring (python2) instead of str
msg198162 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-09-20 19:24
Perhaps we should rather change GzipFile.mode to be a string?
History
Date User Action Args
2013-09-20 19:24:34serhiy.storchakasetmessages: + msg198162
2013-08-03 04:21:56jceasetnosy: + jcea
2013-07-28 18:40:36serhiy.storchakasetnosy: + serhiy.storchaka
dependencies: + Multivolume support in tarfile module
type: behavior

stage: patch review
2013-07-28 15:07:05ned.deilysetnosy: + lars.gustaebel
2013-07-28 08:39:07edulixsetfiles: + gzip.patch

messages: + msg193813
2013-07-28 08:38:09edulixsetfiles: - gzip.patch
2013-07-28 08:35:14edulixcreate