Hi Rick, Thanks for the great questions. I think some misunderstanding could have been avoided here had I copied one important line <https://github.com/a-sully/fs/blob/e82fb4eea28b9964a0e16b3671d779527a7b9bcc/MovingNonOpfsFiles.md#introduction> from the explainer into this Intent:
> When launching SyncAccessHandles, we launched FileSystemFileHandle.move() for files within the Origin Private File System (OPFS). Moving of files outside of the OPFS and moving directories at all are not yet supported. TLDR; moving OPFS files was shipped alongside FileSystemSyncAccessHandles, though it is (quite <https://github.com/whatwg/fs/pull/10#issuecomment-1330789126> regrettably <https://github.com/whatwg/fs/pull/10#issuecomment-1385992738>) not yet specified. The I2S thread for SyncAccessHandles <https://groups.google.com/a/chromium.org/g/blink-dev/c/OR0poFdzEpo/m/z5l7h1-jAQAJ> didn't mention the 'move' method for files. This was a mistake. Going forward, I'd like to ensure other browser engines have a chance to voice their input on new features of this API, even if it's regarding a subset that they don't implement. Sure, I wasn't expecting the most overwhelmingly positive response when I filed Mozilla's standards position, but I strongly believe we should keep that door open <https://github.com/mozilla/standards-positions/issues/738>. For the sake of completeness, see inline responses to the questions below. Otherwise please let me know if I've misunderstood your misunderstanding, or if you have more questions :) On Tue, Jan 24, 2023 at 9:52 AM Rick Byers <rby...@chromium.org> wrote: > Hi Austin, > I've been skimming through the history here but am left a little confused > about how exactly this fits into the larger file system picture. When you > shipped > <https://groups.google.com/a/chromium.org/g/blink-dev/c/tESXuOfqQMQ/m/w-tvoCPYCQAJ> > 'remove' I gather that was for both OPFS and local file use cases, is that > right? > Correct. Going forward, I expect that new features that are relevant to both the OPFS and local files (e.g. if we add a getParent() method <https://github.com/whatwg/fs/issues/38>) will be launched for both at the same time. There's of course the possibility that we think a feature is only relevant to one file system before a compelling use case convinces us otherwise (e.g. I expect file system change events <https://github.com/WICG/file-system-access/issues/72> to only be relevant for local files), but my hope is that we don't find ourselves in that situation often. Regardless, I'll make sure to be explicit about the scope of a new feature in future Intents! Why is this intent scoped to just local file use cases? > See above I know the other engines don't support local file system access, but their > opinion (and TAG's opinion) on the API for OPFS cases seems relevant to how > we reason about this intent. But as long as we're asking for signals > specific to the local file system use case, I wouldn't expect that we'll > get anything of value (as in the Mozilla standards position response > <https://github.com/mozilla/standards-positions/issues/732#issuecomment-1396391008>). > I see there's a chromestatus entry > <https://chromestatus.com/feature/5640802622504960> for move generally, > what's the status of that? > Ideally, we would've shipped move more generally (for local files + for directories) alongside, or at least shortly after, shipping SyncAccessHandles. Unfortunately, the timelines we were under didn't afford time to address all the privacy and security concerns for non-OPFS moves. So non-OPFS file moves were punted until now, and we're still punting on directory moves for now while we sort out some significant open questions <https://github.com/whatwg/fs/issues/59> that need to be resolved before we can specify directory moves in a way that's consistent across browser engines. Any reason why we can't focus on getting consensus for move() generally as > supported broadly in OPFS, and then separately talk about details (if any) > for local access? > See above > Thanks, > Rick > > On Fri, Jan 20, 2023 at 4:51 PM Austin Sullivan <asu...@chromium.org> > wrote: > >> Contact emails >> >> asu...@chromium.org >> >> Specification >> >> https://github.com/whatwg/fs/pull/10 >> >> Design docs >> >> https://github.com/a-sully/fs/pull/2 >> >> Summary >> >> Support efficient moves and renames of local files (i.e. user-visible >> files on the device) with the File System Access API. >> >> Efficient file moves is a core API primitive that dramatically improves >> the viability of a number of applications on the web. For example, renaming >> a large video file currently requires obtaining access to a new file, >> copying all the data, and removing the original. This is slow, error-prone >> (ex: out of quota), and a poor developer and user experience. >> >> >> Blink component >> >> Blink>Storage>FileSystem >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage%3EFileSystem> >> >> Search tags >> >> file <https://chromestatus.com/features#tags:file>, system >> <https://chromestatus.com/features#tags:system>, access >> <https://chromestatus.com/features#tags:access>, move >> <https://chromestatus.com/features#tags:move>, rename >> <https://chromestatus.com/features#tags:rename>, opfs >> <https://chromestatus.com/features#tags:opfs> >> >> TAG review >> >> https://github.com/w3ctag/design-reviews/issues/805 >> >> TAG review status >> >> Pending >> >> Risks >> Interoperability and Compatibility >> >> Gecko: Negative to local file access more broadly, and therefore this >> addition (https://github.com/mozilla/standards-positions/issues/732) >> >> WebKit: No signal on this addition ( >> https://github.com/WebKit/standards-positions/issues/121) or local file >> access in general ( >> https://github.com/WebKit/standards-positions/issues/28) >> >> Web developers: Strongly positive ( >> https://github.com/WICG/file-system-access/issues/64) >> >> Other signals: >> >> Ergonomics >> >> See the "Improve the ergonomics of the API" section of the explainer >> >> Security >> >> See the "Security Considerations" section of the explainer >> >> WebView application risks >> >> N/A >> >> Debuggability >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, Chrome OS, Android, and Android WebView)? >> >> No, accessing local files with the File System Access API is not >> supported on Android >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? >> >> Yes >> >> Flag name >> >> kFileSystemAccessMoveNonOpfsFiles >> >> Requires code in //chrome? >> >> False >> >> Launch bug >> >> https://launch.corp.google.com/launch/4200956 >> >> Estimated milestones >> >> M111 >> >> Anticipated spec changes >> >> No anticipated inter-op issues with file moves. Directory moves are being >> punted for now while we resolve inter-op issues (see >> https://github.com/whatwg/fs/issues/59 for more context) >> >> Link to entry on the Chrome Platform Status >> >> https://chromestatus.com/feature/6271579653144576 >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com/>. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnvaEXisJRYpRYJtRW%2BYiN_eL27opNRvjH6U3v0R6nHV8tEtA%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnvaEXisJRYpRYJtRW%2BYiN_eL27opNRvjH6U3v0R6nHV8tEtA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnvaEUTsSJbaRoSoAKVSJTUpFTeq%3D3yykwVa5sAXdYkP5sZ9w%40mail.gmail.com.
