Repository navigation
Fixing tarfile._mode when using gzip via ":gz" #62775
Description
| BPO | 18575 |
|---|---|
| Nosy | @jcea, @gustaebel, @serhiy-storchaka |
| Dependencies | |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2013-07-28.08:35:14.482>
labels = ['type-bug', 'library']
title = 'Fixing tarfile._mode when using gzip via ":gz"'
updated_at = <Date 2013-09-20.19:24:34.339>
user = 'https://bugs.python.org/edulix'bugs.python.org fields:
activity = <Date 2013-09-20.19:24:34.339>
actor = 'serhiy.storchaka'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2013-07-28.08:35:14.482>
creator = 'edulix'
dependencies = ['18321']
files = ['31062']
hgrepos = []
issue_num = 18575
keywords = ['patch']
message_count = 3.0
messages = ['193812', '193813', '198162']
nosy_count = 4.0
nosy_names = ['jcea', 'lars.gustaebel', 'serhiy.storchaka', 'edulix']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue18575'
versions = ['Python 3.4']
Activity
edulix commentedon Jul 28, 2013
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 bpo-18321.
edulix commentedon Jul 28, 2013
Fixing gzip.patch, it was using basestring (python2) instead of str
serhiy-storchaka commentedon Sep 20, 2013
Perhaps we should rather change GzipFile.mode to be a string?
serhiy-storchaka commentedon Apr 21, 2024
It is now a string since #115961.