Repository navigation
shutil.copytree error handling non-standard and partially broken #52217
Description
| BPO | 7969 |
|---|---|
| Nosy | @terryjreedy, @tarekziade, @merwok, @dhduvall |
| 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 = 'https://github.com/merwok'
closed_at = None
created_at = <Date 2010-02-19.22:04:16.853>
labels = ['type-bug', 'library']
title = 'shutil.copytree error handling non-standard and partially broken'
updated_at = <Date 2011-06-15.13:40:35.619>
user = 'https://bugs.python.org/swalker'bugs.python.org fields:
activity = <Date 2011-06-15.13:40:35.619>
actor = 'eric.araujo'
assignee = 'eric.araujo'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2010-02-19.22:04:16.853>
creator = 'swalker'
dependencies = []
files = ['22026']
hgrepos = []
issue_num = 7969
keywords = ['patch']
message_count = 8.0
messages = ['99597', '103685', '136061', '136268', '138083', '138225', '138325', '138367']
nosy_count = 6.0
nosy_names = ['terry.reedy', 'tarek', 'eric.araujo', 'dhduvall', 'swalker', 'lokare.ameya']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue7969'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3']
Activity
swalker commentedon Feb 19, 2010
The error handling present in the implementation of shutil.copytree in python 2.6.4 (and perhaps other versions) is non-standard and partially broken.
In particular, I'm unable to find any pydoc documentation that indicates that when copytree raises shutil.Error, that the error instead of the standard 2-tuple or 3-tuple was initialised with a list of entries.
This means that callers catching EnvironmentError will be in for a surprise whenever they check e.args and find a tuple containing a list instead of just a tuple.
Callers will also be disappointed to find that the entries in the list may be tuples or strings due to what looks like a bug in copystat error handling (it's using extend instead of append).
I could possibly live with this behaviour somewhat if it was actually documented and consistent since shutil.Error can be caught specifically instead.
It's also really unfortunate that the tuples that are stored here aren't the actual exception objects of the errors encountered so callers cannot perform more granular error handling (permissions exceptions, etc.).
I'd like to request that this function:
be fixed to append copystat errors correctly
have shutil.Error documentation indicate the special args format and explain how it might be parsed
consider having it record the exception objects instead of the exception message
suggest that the default str() output for shutil.Error be improved
tarekziade commentedon Apr 20, 2010
I agree with all your points.
The copystat error can be fixed right away and applied for 2.6 to 3.x
For other points, I'll change the way the Error works but this will require an heavy deprecation process.
In the meantime I can document the behavior, and provide some examples in the documentation (eg how to catch and manage the errors that were raised)
terryjreedy commentedon May 16, 2011
I also found the doc confusing. Does "This exception collects exceptions that raised during a multi-file operation." that Error is used for .rmtree or .move? If so, what format. If not, revise. And I also wondered how to access and use an Error.
lokareameya commentedon May 19, 2011
I've attached a proposed doc patch. I figured I'd move the Error argument format in the description of shutil.copytree, since the format is different for other functions (shutil.move, for example).
merwok commentedon Jun 10, 2011
Thanks for the patch. Have you had a chance to investigate Terry’s question?
lokareameya commentedon Jun 13, 2011
shutil.Error is raised in copytree, copyfile and move, with a different format in each case. I was thinking the Error argument format could be documented in the descriptions of these functions (possibly with some examples). What do you think?
merwok commentedon Jun 14, 2011
I think it would be good.
merwok commentedon Jun 15, 2011
See also http://mail.python.org/pipermail/docs/2010-August/001207.html for a similar report.