commit 0cd28584b5bbd8be4853e6e2840bff7b322a859d
author arostovtsev <arostovtsev@google.com> Tue May 05 10:19:02 2020 -0700
committer Copybara-Service <copybara-worker@google.com> Tue May 05 10:20:07 2020 -0700
tree 55ac92e938249b5f61e19caf6c2147b98cf4b6ba
parent 044b0b864df0fdf3b11df15eb1645051bdb9e638

Fix deletion of non-executable but readable directories

Deleting a non-executable directory is tricky; the opendir/readdir syscalls on the
directory itself will succeed (and return the full list of directory entries), but
any filesystem operation on the entries (stat, open, unlink, etc.) will fail with
EACCES.

In Java, the behavior of FileSystem method calls for listing and deleting directory
entries depends on whether or not the particular implementation stats the entries or
not. In any case, deletion of entries requires the directory permissions to be
changed.

The trivial fix would be to set directory executable (and readable and writable)
before calling deleteTree() or deleteTreesBelow() - but that would carry an
unacceptable cost in the number of system calls to address what should be a rare
situation.

Instead, in UnixFileSystem's jni code, we can check if errno == EACCES after the
first filesystem operation on a directory entry, and if so, change permissions.

In the generic Java FileSystem implementation, we can't see errno, so we have to
* introduce a new deleteStrict() method which (unlike delete()) throws instead of
  returning false when attempting to delete an entry that the FileSystem cannot
  stat; and
* fix permissions and retry recursive deletion when deleteStrict() throws.

Fixes #11010 (also see discussion in PR #11045).

RELNOTES: Bazel can now recursively delete non-executable but readable directories.
PiperOrigin-RevId: 309970825