classification
Title: tempfile.TemporaryDirectory fails to delete itself
Type: behavior Stage:
Components: Library (Lib), Windows Versions: Python 3.7, Python 3.6
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: serhiy.storchaka Nosy List: Jeffrey.Kintscher, gvanrossum, max, paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2017-04-04 18:26 by max, last changed 2019-06-12 23:23 by Jeffrey.Kintscher.

Messages (2)
msg291130 - (view) Author: Max (max) * Date: 2017-04-04 18:26
There's a known issue with `shutil.rmtree` on Windows, in that it fails intermittently. 

The issue is well known (https://mail.python.org/pipermail/python-dev/2013-September/128353.html), and the agreement is that it cannot be cleanly solved inside `shutil` and should instead be solved by the calling app. Specifically, python devs themselves faced it in their test suite and solved it by retrying delete.

However, what to do about `tempfile.TemporaryDirectory`? Is it considered the calling app, and therefore should retry delete when it calls `shutil.rmtree` in its `cleanup` method?

I don't think `tempfile` is protected by the same argument that `shutil.rmtree` is protected, in that it's too messy to solve it in the standard library. My rationale is that while it's very easy for the end user to retry `shutil.rmtree`, it's far more difficult to fix the problem with `tempfile.TempDirectory` not deleting itself - how would the end user retry the `cleanup` method (which is called from `weakref.finalizer`)?

So perhaps the retry loop should be added to `cleanup`.
msg292562 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2017-04-29 04:17
A simpler approach would be to simply ignore the error when it occurs in TemporaryDirectory._cleanup. There are no absolute guarantees about tempfile always cleaning up -- just a best effort. The complexity (and potential delays) of a retry loop seem more risky than simply occasionally not cleaning up -- that happens anyways, for a variety of reasons.
History
Date User Action Args
2019-06-12 23:23:48Jeffrey.Kintschersetnosy: + Jeffrey.Kintscher
2018-11-03 20:05:56serhiy.storchakasetassignee: serhiy.storchaka

nosy: + serhiy.storchaka
2017-04-29 04:17:34gvanrossumsetnosy: + gvanrossum
messages: + msg292562
2017-04-04 20:24:46eryksunsetnosy: + paul.moore, tim.golden, zach.ware, steve.dower

components: + Windows
versions: + Python 3.7
2017-04-04 18:26:18maxcreate