This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: shutil.rmtree should not fail with FileNotFoundError (race condition)
Type: behavior Stage: patch review
Components: Library (Lib) Versions:
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Jeffrey.Kintscher, coroa, dkg, giampaolo.rodola, iritkatriel, jesse.farnham, noamda, serhiy.storchaka
Priority: normal Keywords: patch

Created on 2017-03-02 19:12 by dkg, last changed 2022-04-11 14:58 by admin.

File name Uploaded Description Edit
breaker.c dkg, 2017-03-02 19:12 C program to tickle the shutil.rmtree race condition dkg, 2017-03-02 19:13
Pull Requests
URL Status Linked Edit
PR 13580 closed Jeffrey.Kintscher, 2019-05-26 03:23
Messages (10)
msg288822 - (view) Author: Daniel Kahn Gillmor (dkg) * Date: 2017-03-02 19:12
There is a race condition in shutil.rmtree, where if a file gets removed between when rmtree plans to remove it and when it gets around to removing it, a FileNotFound exception gets raised.

The expected semantics of rmtree imply that if the filesystem tree is removed, then the command has succeeded, so it doesn't make sense for rmtree to raise a FileNotFound error if someone else happened to have deleted the file before rmtree gets to it.

I'm attaching a C program (for GNU/Linux) which uses inotify to remove the other file in a directory when either file is removed.  This triggers the rmtree failure.

This behavior has caused a number of workarounds in external projects, like:;a=commitdiff;h=de8494b16bc50c60a8438f2cae1f8c88e8949f7a

It would be better for shutil.rmtree to ignore this particular exception (FileNotFoundError).

Another option for users is to set ignore_errors=True, but this ends up ignoring *all* errors, which doesn't seem like the right decision.

Finally, of course, a user could specify some sort of onerror function that explictly ignores FileNotFoundError, but this seems pretty complicated for the common pattern.

It's possible that shutil.rmtree() wants to raise FileNotFoundError if the actual argument passed by the user does not itself exist, but it really doesn't make sense to raise that error for any of the elements further down in the tree.
msg288823 - (view) Author: Daniel Kahn Gillmor (dkg) * Date: 2017-03-02 19:13
and here is python demonstration script that will build breaker.c and then use it to cause the error to be raised from shutils.rmtree.

the output of looks like this:

make: 'breaker' is up to date.
Traceback (most recent call last):
  File "./", line 14, in <module>
  File "/usr/lib/python3.5/", line 480, in rmtree
    _rmtree_safe_fd(fd, path, onerror)
  File "/usr/lib/python3.5/", line 438, in _rmtree_safe_fd
    onerror(os.unlink, fullname, sys.exc_info())
  File "/usr/lib/python3.5/", line 436, in _rmtree_safe_fd
    os.unlink(name, dir_fd=topfd)
FileNotFoundError: [Errno 2] No such file or directory: 'b'
msg319374 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2018-06-12 10:20
+1. It looks reasonable to ignore FileNotFoundError on os.rmdir(),  os.unlink() and also and os.scandir().
msg321458 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2018-07-11 14:32
Shouldn't this be considered as a new feature? There are no guaranties that shutil.rmtree() should work if files or directories are concurrently removed, or created, or made read-only in other threads or processes.
msg343530 - (view) Author: Jeffrey Kintscher (Jeffrey.Kintscher) * Date: 2019-05-26 04:05
I created pull request bpo-29699 to fix this issue. It adds an additional exception handler to ignore FileNotFoundError for most of the try blocks that already handle OSError.

I decided not to add it to the initial call. This should provide the same semantics as the "rm -r" shell command. It will fail with FileNotFoundError when foo is missing, which is the same behavior as "rm -r foo" returning "rm: foo: No such file or directory" when foo is missing. Similarly, "rm -rf foo" always succeeds and is equivalent to setting "ignore_errors=true" in the shutil.rmtree() call.
msg396167 - (view) Author: Noam (noamda) Date: 2021-06-20 11:07
Is this still alive? If decided to decline PR why is this still open?
msg396177 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2021-06-20 14:54
seel also issue37260
msg396185 - (view) Author: Noam (noamda) Date: 2021-06-20 17:35
Hi Irit, 

Sorry, I'm still not following, 

The other issue you stated, states that PR is ready(06-2019), and this was in 2019, is this going to be fixed? or declined (and both should be closed)?

What is the current updated status?
msg396186 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2021-06-20 18:18
PR13580 was not declined, the reviewer requested unit tests. If you want to advance this, perhaps you can help fill that in.

The other PR looks like a duplicate that should be closed.
msg408570 - (view) Author: coroa (coroa) Date: 2021-12-14 21:57
Just realised that the "race condition" is triggered consistently on Mac OSX machines working on non-Mac filesystems, where they store extended attributes like last access time in meta files with a `._` prefix. These files are listed by `os.scandir` after their original files and are removed, as soon as the original file is unlinked.

Ie. a test.txt, ._test.txt pair will always raise FileNotFoundError for ._test.txt since the file system driver itself already removed it when the unlink on test.txt was executed.

Refer also to

Current status seems to be:
1. and are duplicates.
2. linked from here has been closed due to lack of unit tests (but with the possibility to re-open after providing those)
3. is still open and seems to be mostly the same patch, does have unit tests and awaiting a second review.

What is the next step?
Date User Action Args
2022-04-11 14:58:43adminsetgithub: 73885
2021-12-14 21:57:38coroasetnosy: + coroa

messages: + msg408570
versions: - Python 3.5
2021-06-20 18:18:04iritkatrielsetmessages: + msg396186
2021-06-20 17:35:30noamdasetmessages: + msg396185
2021-06-20 14:54:39iritkatrielsetnosy: + iritkatriel
messages: + msg396177
2021-06-20 11:07:04noamdasetnosy: + noamda
messages: + msg396167
2019-05-26 04:05:51Jeffrey.Kintschersetmessages: + msg343530
2019-05-26 03:23:32Jeffrey.Kintschersetkeywords: + patch
stage: patch review
pull_requests: + pull_request13487
2019-05-22 09:06:12Jeffrey.Kintschersetnosy: + Jeffrey.Kintscher
2019-04-09 15:08:48jesse.farnhamsetnosy: + jesse.farnham
2018-07-11 14:32:37serhiy.storchakasetmessages: + msg321458
2018-07-11 14:23:10vstinnersetnosy: + serhiy.storchaka
2018-07-11 07:55:24serhiy.storchakasettype: crash -> behavior
2018-06-12 10:20:29giampaolo.rodolasetnosy: + giampaolo.rodola
messages: + msg319374
2017-03-02 19:13:29dkgsetfiles: +

messages: + msg288823
2017-03-02 19:12:24dkgcreate