Require an exclusive lock in removeEntry()

[a-sully]

For the sake of backwards compatibility, removeEntry() currently only requires acquiring a shared lock in Chromium (though this is not specified). This means that you cannot remove a file with an open Access Handle, but you can remove a file with an open WritableFileStream. See https://github.com/whatwg/fs/issues/34#issuecomment-1273961101 for context.

The removeEntry() method should take an exclusive lock, matching #9. At least until we change the locking paradigm to not be based on "exclusive" and "shared" locks in #34.

• [ ] At least two implementers are interested (and none opposed):
  • All implementers have expressed support that this should match remove() in https://github.com/whatwg/fs/issues/34
• [ ] Tests are written and can be reviewed and commented upon at:
  • …
• [ ] Implementation bugs are filed:
  • Chromium: https://crbug.com/1254078
  • Gecko: …
  • WebKit: …
• [ ] MDN issue is filed: …

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[a-sully]

Update: removeEntry() has been taking an exclusive lock on Chromium browsers for a while now. See https://crbug.com/1254078

This PR is also incorrect as written, since the lock should not be on the directory itself but on the child being removed. I'll update that before sending for review...

Anyways, I filed #138 to track updating updating the spec both for removeEntry() and remove()