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.