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

Created on 2017-03-02 19:12 by dkg, last changed 2021-06-20 18:18 by iritkatriel.

Files
File name Uploaded Description Edit
breaker.c dkg, 2017-03-02 19:12 C program to tickle the shutil.rmtree race condition
demo.py dkg, 2017-03-02 19:13
Pull Requests
URL Status Linked Edit
PR 13580 open Jeffrey.Kintscher, 2019-05-26 03:23
Messages (9)
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:

  https://bitbucket.org/vinay.sajip/python-gnupg/commits/492fd45ca073a90aac434320fb0c8fe8d01f782b
  https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;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 demo.py looks like this:

make: 'breaker' is up to date.
Traceback (most recent call last):
  File "./demo.py", line 14, in <module>
    shutil.rmtree('xx')
  File "/usr/lib/python3.5/shutil.py", line 480, in rmtree
    _rmtree_safe_fd(fd, path, onerror)
  File "/usr/lib/python3.5/shutil.py", line 438, in _rmtree_safe_fd
    onerror(os.unlink, fullname, sys.exc_info())
  File "/usr/lib/python3.5/shutil.py", 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 os.open() 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 os.open() 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.
History
Date User Action Args
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: + demo.py

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