Multiple Readers and Writers in File System Access API

[dslee414]

こんにちは TAG-さん!

I'm requesting a TAG review of Multiple Readers and Writers in File System Access API.

Currently, only one FileSystemSyncAccessHandle may be open at a time per file, preventing an origin from reading the same file from multiple tabs easily. Conversely, multiple FileSystemWritableFileStream can be simultaneously open, letting multiple writers clobber each other.

Introducing new “create” modes for FileSystemSyncAccessHandle and FileSystemWritableFileStream allows opening either multiple readers/writers or an exclusive writer to a file entry, depending on the application's use case.

handle.createSyncAccessHandle({ mode: 'read-only' });
handle.createWritable({ mode: ‘exclusive’ });

• Explainer: https://github.com/whatwg/fs/blob/main/proposals/MultipleReadersWriters.md
• Security and Privacy self-review: No changes introduced to the existing review (WICG/file-system-access/security-privacy-questionnaire.md)
• GitHub repo: whatwg/fs
• Primary contacts:
  • Austin Sullivan (@a-sully), Google Chrome
  • Daseul Lee (@dslee414), Google Chrome
• Organization/project driving the design: Google/Chromium
• External status/issue trackers for this feature: https://bugs.chromium.org/p/chromium/issues/detail?id=1382215

Further details:

• [x] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done: whatwg/fs and WICG/file-system-access
• The group where standardization of this work is intended to be done: whatwg/fs
• Existing major pieces of multi-stakeholder review or discussion of this design: https://github.com/whatwg/fs/issues/34
• Major unresolved issues with or opposition to this design: Webkit is positive in regards to allowing multiple read-only FileSystemSyncAccessHandles, but the stance for multiple writers is not yet known.
• This work is being funded by: Google

You should also know that…

• FileSystemSyncAccessHandle is available only on Bucket File System (a.k.a. Origin Private File System), while FileSystemWritableFileStream is available on both Bucket File System (implemented in Blink, Gecko, WebKit) and local file system (Chromium-only).
• We think that adding an optional dictionary is probably not controversial, and adding modes like shared read-only, exclusive readwrite, and (unsafe) shared readwrite are common across native file system APIs, but feedback on the specific enum strings would be especially welcome.
• Also, we think that preventing modification of a parent directory via shared lock would be desired, as a file entry is represented by a file path; however, native file system behavior on this varies, and feedback on this is welcome.

We'd prefer the TAG provide feedback as:

🐛 open issues in our GitHub repo for each point of feedback

[fergald]

Security and Privacy self-review: No changes introduced to the existing review (WICG/file-system-access/security-privacy-questionnaire.md)

The questionnaire has changed somesince then, for example the old questionnaire does not cover BFCache. We're discussing that elsewhere but there may be other changed to the questionnaire that make it worth revisiting.

[cynthia]

We briefly discussed this during our F2F, overall - this looks good. However, we couldn't see how the lock is expected to behave when the document becomes not fully active, or if the rug is pulled from underneath (e.g. crash). Effectively, there doesn't seem to be a mechanism in place for recovery; or getting out of a stale lock state. Could you elaborate on what you have in mind here and possibly add that to the explainer?

Also, the other implementer signal is a pointer to a long thread, where we can't really identify who is from which implementer. It would be helpful if there was at least a pointer to the actual comment from each implementer. (Ideally we'd want to see a standards position.)

[nathanmemmott]

We briefly discussed this during our F2F, overall - this looks good. However, we couldn't see how the lock is expected to behave when the document becomes not fully active, or if the rug is pulled from underneath (e.g. crash). Effectively, there doesn't seem to be a mechanism in place for recovery; or getting out of a stale lock state. Could you elaborate on what you have in mind here and possibly add that to the explainer?

For a page crash, all locks associated with that page will be maintained by a process associated with the user agent. So if the user agent crashes the lock is released. This is similar to how flock is owned by the file descriptor, so if the process that owns the file descriptor crashes, then the lock is released when the file descriptor is unallocated (https://man7.org/linux/man-pages/man2/flock.2.html).

Interaction with BFCache is already an issue without introducing the new locking scheme and is discussed here: whatwg/fs#17. From that discussion, we'd like to evict a page in BFCache only on contention of a fully active page's FSA locks with the BFCached page's FSA locks. I'll update the explainer to have a section explaining that.

Also, the other implementer signal is a pointer to a long thread, where we can't really identify who is from which implementer. It would be helpful if there was at least a pointer to the actual comment from each implementer. (Ideally we'd want to see a standards position.)

We forgot to request standards positions. I'll do that now!

[cynthia]

Thanks for the quick response. We'll wait for the updates and standards position - let's resume the discussion when we have those.

[cynthia]

Given the response above, and the multiple stakeholder support, we're happy to see this proposal move forward. Thanks for bringing this to our attention!