Origin Private File System (OPFS): File System API vs. File System Access API

[js-choi]

This issue is about the Origin Private File System (OPFS) API and CanIUse’s entry for “File System Access”.

It would be informative for developers if these links were added to the Resources tab for File System Access:

• Firefox support bug for Origin Private File System
• WebKit blog post for Origin Private File System

In addition, this line:

• Firefox position: harmful

…probably should be changed to something like:

• Firefox intent to prototype Origin Private File System access
• Firefox position: harmful (when not restricted to Origin Private File System)

Eventually, we should split CanIUse’s entry on File System Access into (1) an entry for FileSystemSyncAccessHandle with OPFS (implemented by Chromium, WebKit, and soon Firefox) and (2) an entry for non-sanboxed File System Access (including both FileSystemSyncAccessHandle on non-sandboxed files and showOpenFilePicker etc., and implemented only by Chromium).

Background

CanIUse currently classifies Origin Private File System (OPFS) under the entry for File System Access (see #6570)…despite its description saying: “API for manipulating files in the device's local file system (not in a sandbox).”

OPFS’s situation is pretty confusing for developers, due to unclear distinctions between the File System Access incubator spec, the File System WHATWG standard, and the FileSystemSyncAccessHandle API (the latter of which would enable, e.g., SQLite using files from storage). File System Access builds on File System, it is File System and not File System Access that defines OPFS, and the FileSystemSyncAccessHandle API is seemingly defined in both File System and File System Access. File System Access also defines systems for allowing websites to non-sandboxed files, along with FileSystemSyncAccessHandle (which, again, is also defined in File System).

Safari has implemented FileSystemSyncAccessHandle specifically for OPFS files. The edit: old version of the WebKit announcement article confusingly refers to this as implementing “File System Access with [OPFS]” but does not refer to the “File System” standard in which FileSystemSyncAccessHandle and OPFS are defined. [Edit: After feedback from @annevk shortly after this issue’s post, the new version of the WebKit article now refers to the “File System API” rather than the “File System Access API”.]

At the same time, Mozilla has evaluated the general “File System Access API” to be Harmful, which includes not just the FileSystemSyncAccessHandle API but also systems for allowing websites to non-sandboxed files. However, Mozilla has given positive responses specifically to the OPFS “subset” of FileSystemSyncAccessHandle, and it is actively implementing “OPFS”.

To add to the confusion, Mozilla’s announcement of its intent to prototype “OPFS” calls out Safari’s announcement about “File System Access with OPFS”…while confusingly saying that they are implementing OPFS from the File System API and rejecting File System Access in general. This seems to mean that they are implementing FileSystemSyncAccessHandle with OPFS but not non-sandboxed files.

Furthermore, Mozilla has added a “Firefox position: positive” entry to its standards positions for “File System” (see mozilla/standards-positions#614 and mozilla/standards-positions#562 (comment)), and Mozilla’s intent is to include FileSystemSyncAccessHandle (with OPFS) in its positive position on “File System” and not in its negative position on “File System Access”. (@annevk: “Note that the linked issue is technically for AccessHandle [with OPFS] which will be part of this [File System] standard (but are not yet). It seems good to have a position on the full [File System] standard that will eventually include it.”)

Exacerbating the confusion is that Google’s developer guidance on OPFS refers to the File System Access API but not File System API.

The MDN overview article for FileSystemFileHandle’s API also refers to “File System Access” and not “File System”.

Lastly, the Chrome Platform Status entry for “File System API” actually refers to the older File and Directory Entries API, a completely different API. Chrome Platform Status also has an entry for “File System Access API”, which seems to track FileSystemSyncAccessHandle for both OPFS and non-sandboxed files (i.e., both File System API and File System Access API).

All in all, this is a very confusing situation for developers:

1. There is FileSystemSyncAccessHandle with OPFS, which will be implemented by WebKit, Firefox, and Chromium, and which Chromium and [edit: previously] WebKit say is from “File System Access” but Firefox says [edit: now along with WebKit] is from “File System”.
2. There is FileSystemSyncAccessHandle on non-sandboxed files, which is implemented only by Chromium, and which is definitely from “File System Access”.
3. There are other APIs definitely from “File System Access”, like showOpenFilePicker, that work on non-sandboxed files, and which are implemented only by Chromium.

The current CanIUse entry for “File System Access” conflates all of these separate concepts. The end result is that the CanIUse currently might give developers the erroneous impression that Mozilla will not implement FileSystemSyncAccessHandle, even for OPFS, and the erroneous impression that that OPFS (and FileSystemSyncAccessHandle) are part of File System Access but not File System.

It might be a good idea to eventually split the CanIUse’s entry on File System Access into (1) an entry for FileSystemSyncAccessHandle with OPFS (implemented by Chromium, WebKit, and soon Firefox) and (2) an entry for non-sanboxed File System Access (including both FileSystemSyncAccessHandle on non-sandboxed files and showOpenFilePicker etc., and implemented only by Chromium).

As a stopgap for now, simply adding those three links from the beginning of this issue to the current “File System Access” entry may help clarify the confusing situation a bit for developers.

[annevk]

The WebKit post was written shortly after whatwg/fs@f520f35 so that might simply not have been taken into account. I'll see if we can clarify the post. (Edit: it's been clarified.) WebKit tracks the WHATWG File System Standard.

I agree that it's been quite confusing, but the idea is straightforward:

• The WHATWG File System Standard defines the core infrastructure that has cross-browser buy-in.
• The WICG File System Access API builds on that with local file system access and is only tracked by (some?) Chromium-based browsers.

[js-choi]

@annevk: Thanks for clarifying the situation. The update to WebKit’s article (which now refers to the File System API and not the File System Access API) helps a lot.

After WebKit’s article update, it’s become even clearer that there will be an ongoing need for developers to clearly distinguish File System API (and OPFS) from File System Access API.

That makes me feel more strongly that we should split the current CanIUse entry into two entries: one for File System API with OPFS…and one for File System Access API.

We should also do the same splitting to the MDN overview article for FileSystemHandle and OPFS. This article is titled “File System Access API”…despite it citing the File System API as its source specification!
I plan to also open an issue on MDN for this sometime later.

[piyu-sh]

Any updates on this please ? The caniuse entry for opfs still points to https://caniuse.com/native-filesystem-api and it implies opfs is not supported on firefox or safari which is not the case as can be seen from compatibility matrix of mdn filesystemsyncaccesshandle or from this web.dev article