#845: Multiple Readers and Writers in File System Access API

Visit on Github.

Opened May 18, 2023

こんにちは 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’ });

Further details:

  • 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

Discussions

Discussed May 1, 2023 (See Github)

Dan: also related to https://github.com/w3ctag/design-reviews/issues/805

Sangwhan: I will write an async review and we can take it from there.

Comment by @fergald Jun 2, 2023 (See Github)

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.

Discussed Jul 1, 2023 (See Github)

Dan: good to see notes on stakeholder feedback in the Explainer. Also good to see that there is positive feedback on the basic concept. It's not clear how well this meshes with filesystems that aren't how chromium thinks about filesystems.. maybe android/chromeos.. It would be good to see webkit and mozilla standards positions on this.

Sangwhan: ...modern filesystems...

Sangwhan: bfcache ... being put into the cache could break your lock... no way to do a lock override. You'd have to manually override but no API for that.

Dan: comment from Fergal on bfcache...

Sangwhan: and what happens if you crash? API seems fine.

Dan: in the explainer they've mentioned positive signals from mozilla and webkit but the links provided are to a whatwg thread. No standards positions.

Sangwhan: I will add to my feedback.

Comment by @cynthia Aug 1, 2023 (See Github)

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

Comment by @nathanmemmott Aug 1, 2023 (See Github)

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!

Comment by @cynthia Aug 5, 2023 (See Github)

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

Discussed Oct 1, 2023 (See Github)

Dan: Mozilla standards position is positive..

Sangwhan: everyone implements opfs

Dan: is the design okay?

Sangwhan: it's fine. Their response makes sense [closing comment]

Dan: concern being support for different types of filesystems

Sangwhan: that's not on this api, that's a different thing. You can use this with only opfs

Dan: I agree.. right now there's a multistakeholder label but I feel we shouldn't have that. Maybe if it's not intrinsically linked to filesystem access that doesn't have multistakeholder support this should be satisfied?

Sangwhan: this can be satisified. In terms of filesystem access on the web, one mechanism is contentious, OPFS is not contentious. Each origin gets a little virtual filesystem. This implements multiple readers and writers on both of them, but its api that works aainst the handles so it doesn't care about what backend it's using. On the native filesystem support that's another thing, we should have a second discussion about that, it keeps on popping up whenever filesystem comes up.. the backend is very concerning. The APIs for the filesystem access that support both opfs and native are fine.

Dan: okay

we agree to close as satisfied

Comment by @cynthia Oct 10, 2023 (See Github)

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!