Repository navigation
ZipFile and current directory change #54840
Description
| BPO | 10631 |
|---|---|
| Nosy | @loewis, @pitrou, @merwok, @bitdancer, @serhiy-storchaka, @ZackerySpytz |
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 = <Date 2020-06-02.20:17:13.888>
created_at = <Date 2010-12-05.16:49:18.276>
labels = ['type-bug', 'library']
title = 'ZipFile and current directory change'
updated_at = <Date 2020-06-02.20:17:13.888>
user = 'https://bugs.python.org/ocean-city'bugs.python.org fields:
activity = <Date 2020-06-02.20:17:13.888>
actor = 'serhiy.storchaka'
assignee = 'none'
closed = True
closed_date = <Date 2020-06-02.20:17:13.888>
closer = 'serhiy.storchaka'
components = ['Library (Lib)']
creation = <Date 2010-12-05.16:49:18.276>
creator = 'ocean-city'
dependencies = []
files = []
hgrepos = []
issue_num = 10631
keywords = []
message_count = 8.0
messages = ['123428', '123430', '123437', '123450', '123846', '176843', '235449', '370619']
nosy_count = 9.0
nosy_names = ['loewis', 'alanmcintyre', 'pitrou', 'ocean-city', 'eric.araujo', 'Arfrever', 'r.david.murray', 'serhiy.storchaka', 'ZackerySpytz']
pr_nums = []
priority = 'low'
resolution = 'out of date'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue10631'
versions = ['Python 2.7']
Activity
ocean-city commentedon Dec 5, 2010
Is this intended behavior? Creating zipfile.ZipFile with
relative path and changing current directory, relative path
is resolved from new directory not from the directory object
was created.
F:\>py3k
Python 3.2a4+ (py3k, Dec 3 2010, 22:11:05) [MSC v.1200 32 bit (Intel)] on win32
pitrou commentedon Dec 5, 2010
I don't know, but I wouldn't call it a bug either.
In general it's not recommended to change the current directory except at the very beginning of your application.
loewis commentedon Dec 5, 2010
More formally: it's unspecified. I'd like to propose this general principle: If you pass a relative path to some library that gets stored in the library, it's unspecified whether the cwd is consider at the point of passing the path or at the point of using it in some operation.
Applications that want to be cwd-agnostic must always use abspath.
The only exceptions are operations where there is some explicit open() operation that is documented to interpret the path name; for these, it is clear that the cwd is considered inside the open().
bitdancer commentedon Dec 6, 2010
So, Martin, are you then arguing that this should in fact be considered a bug in ZipFile? The documentation for the constructor says "Open a ZIP file, where file can be either a path to a file (a string) or a file-like object." Reading that I would certainly expect it to accept a relative path, and for that path to be relative to the CWD at the time I called ZipFile, not at the time I called extractall.
loewis commentedon Dec 12, 2010
You have a point here. So I now think that this should be changed.
serhiy-storchaka commentedon Dec 3, 2012
The patch from bpo-14099 is intended to fix this issue.
serhiy-storchaka commentedon Feb 5, 2015
Fixed in bpo-14099 for 3.5. Do you think that this solution should be backported Martin?
An alternative solution of this issue would be to convert relative path to absolute path in ZipFile constructor.
ZackerySpytz commentedon Jun 2, 2020
Python 2 is EOL, so I think this issue should be closed.