Intent to Ship: FileSystemFileHandle.move() for local files

[Austin Sullivan]

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

Search tags

file, system, access, move, rename, 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?

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.

[Rick Byers]

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 'remove' I gather that was for both OPFS and local file use cases, is that right? Why is this intent scoped to just local file use cases? 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). I see there's a chromestatus entry for move generally, what's the status of that? 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?

Thanks,

  Rick

--
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+...@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.

[Austin Sullivan]

Hi Rick,

Thanks for the great questions. I think some misunderstanding could have been avoided here had I copied one important line 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 regrettably) not yet specified. The I2S thread for SyncAccessHandles 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.

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 '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) 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 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). I see there's a chromestatus entry 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 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

[slightlyoff via Chromestatus]

LGTM1

[Ajay Rahatekar]

Hello API owners,

The team is targeting M111 for shipping the feature. Please let us know of any questions/comments. 

Thanks in advance.

On Thursday, January 26, 2023 at 11:00:46 AM UTC-8 slightlyoff via Chromestatus wrote:

LGTM1

[Yoav Weiss]

Thanks Austin!

Does the pull request cover both the OPFS and the local file system sides of the API? 

[Chris Harrelson]

LGTM2

--

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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f8774dd3-cb69-454b-a01d-92302d4d2ce5n%40chromium.org.

[Rick Byers]

Thank you Austin. Sorry for my confusion and then my delay in response. So since there's already broad support for FileSystemHandle.move() and chromium has already approved a path for obtaining a FileSystemHandle for a local file, this seems like a pretty minor delta to me to allow them together. Thank you for your commitment to keeping the dialog open, even though chromium has chosen to disagree with other implementers on local file system access.

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9-3bg-%3DvR6AWGGJJTkQGCKSX2zyG6bV%3DykjsmereRuBA%40mail.gmail.com.

[Austin Sullivan]

Thank you all!

On Wednesday, February 1, 2023 at 8:52:21 AM UTC-8 Rick Byers wrote:

Thank you Austin. Sorry for my confusion and then my delay in response. So since there's already broad support for FileSystemHandle.move() and chromium has already approved a path for obtaining a FileSystemHandle for a local file, this seems like a pretty minor delta to me to allow them together. Thank you for your commitment to keeping the dialog open, even though chromium has chosen to disagree with other implementers on local file system access.

LGTM3

On Wed, Feb 1, 2023 at 11:43 AM Chris Harrelson <chri...@chromium.org> wrote:

LGTM2

On Tue, Jan 31, 2023 at 10:12 PM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks Austin!

Does the pull request cover both the OPFS and the local file system sides of the API? 

Yes! The intention is to cover as much as we can in the whatwg/fs spec and have WICG/file-system-access be (as much as possible) only for the interfaces that are specific to local files, such as the picker APIs

 

On Wednesday, February 1, 2023 at 1:44:42 AM UTC+1 ajayra...@google.com wrote:

Hello API owners,

The team is targeting M111 for shipping the feature. Please let us know of any questions/comments. 

Thanks in advance.

On Thursday, January 26, 2023 at 11:00:46 AM UTC-8 slightlyoff via Chromestatus wrote:

LGTM1

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f8774dd3-cb69-454b-a01d-92302d4d2ce5n%40chromium.org.

--
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+unsubscribe@chromium.org.

[Yoav Weiss]

Thanks! Unnecessary LGTM4 :)

[jgrass]

The behavior of renaming files is inconsistent with the native API.

When using the `FileSystemHandle.move` method to rename files, it modifies the "Modified time" of the file. However, this issue does not occur when manually operating or using the native API, as renaming usually does not modify a file's "Modified time".
Is this behavior expected?

Should I report this issue here or somewhere else?

My test environment: Win10, Chrome120.0.6099.129

I also mentioned this issue here. ( https://github.com/whatwg/fs/pull/10 )