object returned by tarfile.extractfile has an incorrect value of name attribute

[xondrejk]

BPO	30282
Nosy	@gustaebel, @xondrejk
PRs	gh-74468: Fix name attribute of extracted object #1483

^{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 2017-05-05.15:09:35.461>
labels = ['3.7', 'type-bug', 'library']
title = 'object returned by tarfile.extractfile has an incorrect value of name attribute'
updated_at = <Date 2017-05-05.20:36:09.009>
user = 'https://github.com/xondrejk'

bugs.python.org fields:

activity = <Date 2017-05-05.20:36:09.009>
actor = 'serhiy.storchaka'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2017-05-05.15:09:35.461>
creator = 'Ondrej Kubecka'
dependencies = []
files = []
hgrepos = []
issue_num = 30282
keywords = []
message_count = 1.0
messages = ['293111']
nosy_count = 2.0
nosy_names = ['lars.gustaebel', 'Ondrej Kubecka']
pr_nums = ['1483']
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue30282'
versions = ['Python 3.3', 'Python 3.4', 'Python 3.5', 'Python 3.6', 'Python 3.7']

Linked PRs

• gh-74468: Fix a mis-taken source of tarfile extracted names #102424

[xondrejk]

Consider the following code snippet:

<snip>
import tarfile

tar1 = tarfile.open('tar1.tar.gz')
file_ = tar1.extractfile('FILE')
print(file_.name)
</snip>

Up until 3.2.x, the value of name attribute would be 'FILE' as derived from tarinfo of the member. Starting with 3.3 (commits: b062a2f 7a919e9) this value be obtained from tarfile.fileobj ("parent" tarball file) and would return 'tar1.tar.gz' instead.

This does not seem to be correct as it's not a filename of the ExFileObject / _FileInFile / io.BufferedReader object itself which would otherwise be consistent with values normally found under name.

There is also a problem that this information no longer appears to be accessible at all looking at the object returned from extractfile alone.

And looking at release notes of 3.3, this does not seem to be intentional effect.