Somewhere in here fileSystem needs to be linked to a specific storage bottle for the correct storage bucket/origin. As written now it reads like there is one shared file system that all the storage buckets access. The old spec didn't really do this rigorously either, so it's probably okay to keep it a little bit hand-wavy (i.e. you might not need to go the whole way towards calling "obtain a local storage bottle map", and making it explicit that all the data for the file system is stored in the returned map), but we certainly don't want the spec to read like there is one "the bucket file system". Each storage bucket does need its own file system.

Let me know if the update makes sense.

Is there a reason this is a class and not just a dictionary? I think in retrospect DOM'sMutationRecord could have just been a dictionary as well. It's also not entirely clear to me why this has a constructor.

I asked the same question, and we had some offline discussion about this. The question of dictionary vs class seems to be the oldest open tag guidance request, but the most recent thinking in the issue thread there (w3ctag/design-principles#11 (comment)) seems to lean arguably in favor of using a class here, or at least not arguing against it (but that guidance certainly has changed a couple of times as the make-up of the tag has changed). I'm not sure what the latest thinking in this area is, and it would be nice if the TAG would actually write up something about this other than in that very long issue thread...

I'm not sure that accurately reflects the upthread discussion though with input from me and@domenic. In particular@domenic made the point there that for observer-related cases where it's just about data a dictionary would be more idiomatic. Having both a class and a constructor for it that takes a dictionary seems quite bloated.

Perhttps://groups.google.com/a/chromium.org/g/blink-dev/c/6oOaFmia2dc/m/gx0KgpQqBQAJ, the latest plan seems to be to use a dictionary, especially since that is easier to upgrade to an interface later. I think that's a good plan, and updating the spec PR to match that would be good.

Switched to dictionary.

Why not(Worker, Window),FileSystemHandle is probably exposed in service worker contexts too?

A separate API would be needed for service workers. The service worker becomes inactive after 30 seconds of no events. The change events received in theFileSystemObserver callback would not count as a service worker event. There are also privacy considerations around allowing a site to observe file changes without the user being aware.

I am not sure whenerrored andunknown would happen.
I guesserrored could happen if unmounting a disk for instance.
I have no clue forunknown.
If we do not have a good usecase, should we remove from the initial PR?
Giving a description explaining what these values are might be nice.

Added definitions for each with examples.

What actions are expected for clients to take for "unknown" or "errored"?
For the use cases inhttps://github.com/whatwg/fs/blob/main/proposals/FileSystemObserver.md, I can see how they may want to react to "created", "deleted" and "content-modified", but not clear about the others.

Also ashttps://github.com/whatwg/fs/blob/main/proposals/FileSystemObserver.md#cross-platform-compatibility mentioned, we should consider about adding types that are generally supported, andunknown seems like platform specific?

For "unknown", they may want to poll their watched directory since they may have missed events. For "errored", they may want to try watching the folder again since they'll no longer be receiving.

unknown seems like platform specific?

An unknown can occur at least on Mac and Windows.

What ismodified meaning?
If only touching the file, will it trigger a FileSystemChange?
If so, I would guess that this could trigger events where no information for the web page has changed (IIRC, access/modification dates are not exposed).
Or maybe it is restricted to changes in the content itself?

Ideally this would only be content changes but we have limited information from the OS APIs so we cannot always filter out metadata changes. There will be some noisiness that a user agent can attempt to filter.

then maybe it should named "content-modified".

If a folder being observed is removed, which callback will be called?
One for the folder, or one per each file in the folder, or depending on the OS?

For each observer, there is only one callback. Each observer registration always has theirroot as the handle that was passed toobserve().

A folder may be moved to a recycling bin or deleted permanently. When moved to the recycling bin, this is interpreted as a move out of scope, so will be reported as one "disappeared" on the folder. When permanently deleted, the OS must delete its descendants recursively before deleting the folder. So a "disappeared" event for each descendant will be reported.

Ismoved also coveringrename change?

Yes

Why is moved event useful? Can we just fire a created change with new path and a deleted event with old path?

We'd lose information if we reported it that way. If we receive a appeared for a/b and a disappeared for a/c, we couldn't tell if that's rename/move or if a/c was just deleted and a/b created.

To avoid duplication registration on the same handle, should the observer be global and have a connect() function instead (or just connect onobserve() if not yet)?

"created" / "deleted" seems more common in file system APIs.

"appeared" and "disappeared" were chosen since these events cover "created"/"moved in to scope" and "deleted"/"moved out of scope" respectively.

then maybe it should named "content-modified".

Why is moved event useful? Can we just fire a created change with new path and a deleted event with old path?

What actions are expected for clients to take for "unknown" or "errored"?
For the use cases inhttps://github.com/whatwg/fs/blob/main/proposals/FileSystemObserver.md, I can see how they may want to react to "created", "deleted" and "content-modified", but not clear about the others.

Also ashttps://github.com/whatwg/fs/blob/main/proposals/FileSystemObserver.md#cross-platform-compatibility mentioned, we should consider about adding types that are generally supported, andunknown seems like platform specific?