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

Make access check algorithms no longer associated with an entry #101

Open
a-sully opened this issue Mar 15, 2023 · 1 comment · May be fixed by #131
Open

Make access check algorithms no longer associated with an entry #101

a-sully opened this issue Mar 15, 2023 · 1 comment · May be fixed by #131

Comments

@a-sully
Copy link
Collaborator

a-sully commented Mar 15, 2023

Access checks are currently tied to a "file system entry". As of #96, a "file system entry" now corresponds to an actual file or directory on disk. We need to support access checks on FileSystemHandles which don't correspond to an entry (e.g. the entry has been removed), so the access checks must be tied to something else.

We could tie access checks to a FileSystemHandle or a "file system locator". See #96 (comment)

@annevk
Copy link
Member

annevk commented Mar 16, 2023

@mkruisselbrink's comment is the one we need more clarity on I think:

Related to my comment above on tying access checks to paths, the current chrome implementation (at least last I looked at it, which admittedly is a while ago, so maybe that has been changed already?) does not guarantee that two handles representing the same path behave the same in all aspects (since for handles acquired via DirectoryHandle.getFileHandle/getDirectoryHandle the access checks are done with the path of the original directory, rather than the path of the current handle).

I'm not saying that shouldn't be changed, but it's certainly something to keep in mind. Perhaps tying access checks to the FileSystemHandle rather than the entry would be a way around that, if we want to keep the same behavior? Although you'd have to figure out how to serialize that properly as well.

Although maybe this already works as we simply share query access and request access with newly created children so they would all end up using the same path.

a-sully added a commit to a-sully/file-system-access that referenced this issue Apr 6, 2023
See WICG#408. This does not completely fix that issue, since there
is still once more reference that will be fixed with
whatwg/fs#101
a-sully added a commit to WICG/file-system-access that referenced this issue Apr 18, 2023
See #408. This does not completely fix that issue, since there is still once more reference that will be fixed with whatwg/fs#101
github-actions bot added a commit to WICG/file-system-access that referenced this issue Apr 18, 2023
See #408. This does not completely fix that issue, since there is still once more reference that will be fixed with whatwg/fs#101

SHA: f0fd3b3
Reason: push, by @a-sully

Co-authored-by: github-actions[bot] <41898282 github-actions[bot]@users.noreply.github.com>
alex292 pushed a commit to alex292/file-system-access that referenced this issue Apr 25, 2023
See WICG#408. This does not completely fix that issue, since there
is still once more reference that will be fixed with
whatwg/fs#101
a-sully added a commit to a-sully/fs that referenced this issue Jun 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

2 participants