Multiple Readers and Writers in File System Access API

[nathanmemmott]

Request for Mozilla Position on an Emerging Web Specification

• Explainer URL (if available): https://github.com/whatwg/fs/blob/main/proposals/MultipleReadersWriters.md
• Mozillians who can provide input (optional): @jesup

Other information

• TAG Design Review: Multiple Readers and Writers in File System Access API w3ctag/design-reviews#845
• Multi-stakeholder discussion of this design: Request for multiple readers via access handles whatwg/fs#34

[janvarga]

Yeah, Firefox already supports writable file streams with the exclusive locking internally, so it's not exposed to content yet. Actually we even provide direct access to the file that way (without any temporary/swap file involved).

[jesup]

I'm in favor (and originally suggested something like this after Adobe raised the multiple-readers case for things like multiple tabs loading a prefs file). For the non SyncAccessHandle case, adding an exclusive options sounds good. This might produce errors for existing applications to deal with where they didn't have to before. For OPFS, the only conflicting accesses would be from the same site's code, so likely that's ok. For non-OPFS, it could in theory require an app to deal with a new error. This is ok to me.

[a-sully]

Thank you for the signs of support!

One thing I think we should align on it the behavior of the "exclusive" mode. The explainer currently proposes the following:

enum FileSystemWritableFileStreamMode { 
  "exclusive", // Only one writer can exist at a time
  "siloed",    // Each writer created will have its own swap file
};

where "exclusive" was expected to still follow the current pattern of writing to a swap file (apologies that this was not explicitly called out in the explainer, which was primarily focused on SyncAccessHandles). It seems prudent to leave the door open to add a third option for exclusive + in-place writes (even if this mode would not be supported when writing to the local file system - WICG/file-system-access#260 has lots of discussion about this). For example:

enum FileSystemWritableFileStreamMode { 
  "exclusive-in-place", // Only one writer can exist at a time, which writes directly to the target file
  "exclusive-atomic",   // Only one writer can exist at a time, which writes to a swap file
  "siloed",             // Each writer created will have its own swap file; last writer to close() wins
};

Thoughts? Happy to move this to a spec issue to further discuss if needed!

[a-sully]

For the non SyncAccessHandle case, adding an exclusive options sounds good. This might produce errors for existing applications to deal with where they didn't have to before.

The default FileSystemWritableFileStreamMode would be "siloed" to match the existing behavior. Since developers would need to opt-in to these new modes, there shouldn't be any breakage! :)

[martinthomson]

Marking as positive based on the feedback from @jesup.

[janvarga]

Only SyncAccessHandle can currently directly access the file. Some developers don't like sync APIs, so providing "exclusive-in-place" access via FileSystemWritableFileStream might look compelling from this point of view.
"Abort" could only close the stream in that case indeed.

[nathanmemmott]

Should we expect to see this on the standards issue tracker?

[sgbeal]

Only SyncAccessHandle can currently directly access the file. Some developers don't like sync APIs...

And some, like the sqlite3 project, really, really, really wishes that they had a fully-synchronous OPFS API. Currently, acquiring a SyncAccessHandle is async, making it exceedingly difficult and imperformant to integrate OPFS with 100% synchronous code like sqlite3's I/O abstraction.