[blink-dev] 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
.

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

Re: [blink-dev] Intent to Ship: FileSystemFileHandle.move() for local files

[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

On Fri, Jan 20, 2023 at 4:51 PM Austin Sullivan  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
> 
>
> 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
> .
>
> --
> 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
> 
> .
>

-- 
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 

Re: [blink-dev] Intent to Ship: FileSystemFileHandle.move() for local files

[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  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


> Thanks,
>   Rick
>
> On Fri, Jan 20, 2023 at 4:51 PM Austin Sullivan 
> 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
>> 
>>
>> Search tags
>>
>> file <