FileSystemHandles follow path semantics and after they or their parent directories have been moved, all affected handles should become invalid, see the discussion at the spefication pipeline https://github.com/whatwg/fs/pull/10

This feature is tested by tests in testing/web-platform/tests/file-system-access/sandboxed_FileSystemDirectoryHandle-move.https.any.js

Depends on D158259

Depends on D158260

I'm concerned that this may cause us to have subtle disagreements with the implementation in chrome (and the spec if it actually gets tight enough to properly spec behavior here). They (the spec/google) seem to be taking a FileSystemFile/DirectoryHandle to be an unresolved path specification. The subtle case here would be if you had something like:

  file = root.createFileHandle("foo", allowCreate);
  file.move("bar");
  file2 = root.createFileHandle("foo", allowCreate);
  handle = file.createSyncAccessHandle();

If FileSystemFileHandles are (potentially) unresolved path specifications, that will work. If they are object references which can be disconnected, then this will fail, I believe. Similar issues occur with directories.

The spec doesn't say which of these is correct, but comments to issues (like on PR 10) strongly imply that these are path representations. We shouldn't commit this without resolving that spec issue. And if they are path representations, then we may need to go back to the older entryIds == hashes of the name. (And there are some complexities with renaming of dirs that have handles to items within them, in both cases)

It certainly would be good to clear any ambiguity in how the handles should work. The tests and some wording in the move API PR expect that after we move an item, all handles which refer to the path represented by the moved handle will respond as if no object exists at that path. The other option would be the current behavior, that all the handles will continue to work as before and the resolve method responds with the new path.

It wouldn't be too hard to even have both kinds of handles simultaneously: the user could specify an option and depending on that, we would either update or not update the version on the parent side.

The latest revision of spec defines FileSystemHandles as paths, or gets rid of FileSystemHandles and uses something with path semantics instead. With path semantics, nothing gets invalidated and this bug is not consistent with that.