Skip to content

feat(services/opfs): add read, write, and stat support#7361

Open
jccampagne wants to merge 2 commits intoapache:mainfrom
jccampagne:wip_opfs_4
Open

feat(services/opfs): add read, write, and stat support#7361
jccampagne wants to merge 2 commits intoapache:mainfrom
jccampagne:wip_opfs_4

Conversation

@jccampagne
Copy link
Copy Markdown

Which issue does this PR close?

This is for OPFS backend: see #5799

Rationale for this change

This is a follow from #7199
Specifically this comment: #7199 (comment)
This is a subset of the full OPFS implementation (wip_opfs_3), focusing on read/write before adding list and delete, to make the PR easier to review.

As I understand it, OPFS as 2 kinds of APIs:

  • synchronous interface: using FileSystemSyncAccessHandle to read and write, can only be used in workers;
  • asynchronous interface: GetFile +FileSystemWritableFileStream, can be using in main JS thread and works, but less efficient.

I decided to go for the async version as it suits my use case (for now), and it it the most generic use case and requires less setup to use (no workers).

I saw the TwoWays trait - that could be used later to implement the alternative using the synch version of OPFS.

Using SendWrapper to make some struct Send and Sync.

Use of buffer consideration

I considered the comment (#7199 (comment)) about using a "buffer":

Also, how about using a buffered writer for OPFS? That way, writes will be faster.

Buffering everything in memory for a single write at close() would increase memory pressure, which is already limited in wasm32. Users who want that behaviour can do it themselves: accumulate data in a buffer, pass it to the OPFS service in one call, and close. Forcing the buffered approach in the service would remove this flexibility; currently users can choose between streaming writes and single-shot buffered writes.

For performance, OPFS offers FileSystemSyncAccessHandle ( https://developer.mozilla.org/en-US/docs/Web/API/FileSystemSyncAccessHandle ) but it's only available in web workers.
A future addition could implement the Sync API for more performance (as suggested in the other PR)

What changes are included in this PR?

Implement core OPFS file operations on top of the existing skeleton:

  • Reader with byte range support via Blob.slice
  • Writer using FileSystemWritableFileStream with WriteParams
  • Stat returning content length and last modified time
  • Proper error mapping from DomException to OpenDAL ErrorKind
  • Root directory support with path normalization
  • Nested directory navigation with optional create

Are there any user-facing changes?

Added write, read, stat.
Added edge tests in core/edge/opfs_wasm32.

AI Usage Statement

Yes, Gemini and Claude to navigate the codebase, documentation; and help with some code.

Implement core OPFS file operations on top of the existing skeleton:
- Reader with byte range support via Blob.slice
- Writer using FileSystemWritableFileStream with WriteParams
- Stat returning content length and last modified time
- Proper error mapping from DomException to OpenDAL ErrorKind
- Root directory support with path normalization
- Nested directory navigation with optional create

This is a subset of the full OPFS implementation (wip_opfs_3),
focusing on read/write before adding list and delete.
@jccampagne jccampagne requested a review from Xuanwo as a code owner April 5, 2026 22:27
@dosubot dosubot bot added size:XL This PR changes 500-999 lines, ignoring generated files. releases-note/feat The PR implements a new feature or has a title that begins with "feat" labels Apr 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

releases-note/feat The PR implements a new feature or has a title that begins with "feat" size:XL This PR changes 500-999 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant