Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require an exclusive lock in removeEntry() #73

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

a-sully
Copy link
Collaborator

@a-sully a-sully commented Nov 2, 2022

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 #34 (comment) 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.

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


Preview | Diff

@@ -656,6 +656,11 @@ The <dfn method for=FileSystemDirectoryHandle>removeEntry(|name|, |options|)</df
1. If |access| is not "{{PermissionState/granted}}",
reject |result| with a {{NotAllowedError}} and abort.

1. Let |lockResult| be the result of [=file entry/lock/take|taking a lock=]
with "`exclusive`" on |entry|.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: we need to ensure that the new locking paradigm covers locked directories appropriately - we should not be able to remove a directory if any contained files are locked, but presumably moving a directory with contained files that are locked is okay

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Filed #137

@a-sully
Copy link
Collaborator Author

a-sully commented Jun 22, 2023

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()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant