Austin Sullivan

Thanks for bringing up these questions! Apologies for the confusion, Move.md is a bit outdated since it was written before the locking mechanisms for SyncAccessHandles were created. I'm planning to...

> Also file.move(dir, "") should fail, per the spec; the wpt tests assume it's the same as file.move(dir) Good catch. We should probably update the WPTs and not the spec?...

SyncAccessHandles grab an exclusive lock on a file, so `removeEntry()` currently isn't allowed, since it grabs a shared lock on the file (the same type of lock acquired by `createWritable()`)....

TLDR: this isn't currently a concern, but will become one soon The primary concern here is that file handles which have acquired locks (these locks are [internal to the File...

Preventing BFCache would certainly work here (this is what the API [currently does in Chromium](https://crsrc.org/c/content/browser/file_system_access/file_system_access_handle_base.cc;l=75-80)), though I think it's worth exploring other options... > Is it reasonable to drop the...

Overall SGTM if we can figure out the edge cases. There's an open issue to better spec locking mechanisms (https://github.com/whatwg/fs/issues/18). We're planning to expand the use of locking soon (in...

The interaction between navigation and sync operations seems like something that's not specific to this API? Presumably other APIs which run code synchronously from workers encounter the same issues?

I agree this is something that should be specified, but I'm not sure if this is the right repo for it. @annevk may know?

We've had a number of requests to expose the full path on the non-standardized portion of the API (https://github.com/WICG/file-system-access/issues/178, for example), but for privacy reasons I don't see us ever...

https://github.com/whatwg/fs/issues/14 is somewhat related