[throwaway284534]

This is honestly very cool. VS Code uses a similar approach to their local file system provider, albeit with a wrapper around IndexDB instead of SQLite. There’s some interesting trade offs too, since IndexDB can store the browser’s native file handlers in a flat map — so there’s no need for a schema.

IMO, the Chrome team is being a bit deceptive with their phrasing on synchronous file handles. The problem is that the entire API is wrapped up in an asynchronous ceremony. `createSyncAccessHandle` is only available in a worker context. So you can only communicate with the worker using an asynchronous postMesssage event dispatcher. And even when you’re in the worker, file handles can only be accessed through methods that return a promise.

I understand the need for such boundaries when working with a single threaded language, but limiting the synchronous APIs to just workers seems like one too many layers of indirection. I recently attempted to write a POSIX-style BusyBox library and this sort of thing was a total show stopper.

[bobkazamakis]

>limiting the synchronous APIs to just workers seems like one too many layers of indirection

An unresponsive script is slowing this window down - kill process ot wait?

[throwaway284534]

The file handler is already tucked inside an asynchronous Promise based API. I think it’s reasonable that a mere attempt to get a handler synchronously is made possible. Whether to support synchronous read/write access is another matter.

I would be delighted if handlers were more akin to byte arrays that could be written and read synchronously, albeit with an asynchronous function to persist changes to the disk.