Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a autoClose flag to FileSystemCreateWritableOptions #236

Closed
mkruisselbrink opened this issue Oct 6, 2020 · 3 comments
Closed

Add a autoClose flag to FileSystemCreateWritableOptions #236

mkruisselbrink opened this issue Oct 6, 2020 · 3 comments
Milestone

Comments

@mkruisselbrink
Copy link
Contributor

Currently you need to explicitly close a FileSystemWritableFileStream for the changes written to it to be flushed to disk. Usually this is a good thing, since it means that a website won't accidentally overwrite a file with a partial version of the file if for whatever reason the website is closed while it is writing to a file. I.e. changes are written to a temporary file and then atomically moved into place.

Sometimes websites to want to be able to write partial data to files though. For example in the case of an audio or video recorder it might be totally reasonable to just want to write however much data could be written, even if the app is closed unexpectedly.

To support that I propose adding a autoClose flag to FileSystemCreateWritableOptions. By default this is false, keeping the existing behavior. But if it is set to true, changes will be written to the target file even if the stream isn't explicitly closed (when the stream gets garbage collected/the page owning it gets closed). A website can still abort the write by calling abort() on the stream, and websites should still call close() to make sure the data gets moved into place as soon as feasible (relying on garbage collection would it make it very unpredictable when the changes show up on disk).

There is some overlap between this and earlier ideas for an "in-place" mode, but in-place mode makes things like safe browsing and other security checks much harder. So with no clear way forward for in-place, this will at least cover some of its use cases.

@mkruisselbrink mkruisselbrink added this to the V2 milestone Oct 6, 2020
@williamiced
Copy link

If a FileSystemWritableFileStream is opened with the autoClose flag is true but is never written, does it also make sense to remove the empty file which is generated by the API when leaving the page?

blueboxd pushed a commit to blueboxd/chromium-legacy that referenced this issue Nov 17, 2020
- This CL contains no behavioral changes
- NFSManager stores flat_set of NFSWriterImpls rather than a
  UniqueReceiverSet of blink::mojom::NFSWriters
- FileWriter destroys itself via disconnect handler
- Opens the door for autoClose flag as described here:
  WICG/file-system-access#236

Bug: 1135687
Change-Id: Icbc7375174ee2d48dca481d6490d5eddc282ccff
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2523653
Auto-Submit: Austin Sullivan <asully@chromium.org>
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#828009}
@williamiced
Copy link

Hi Marijn, do we have any progress about this issue?

Chrome Camera app (one of the built-in CrOS app) is using this API.
However, when closing the app without stopping the video recording, the API still writes an empty file to the file system, which is a behavior we would like to avoid.

Is it possible to implement the part to make the API not writing empty file when the app is closed first?
Thanks and please let me know if there is anything I can help.

@a-sully
Copy link
Collaborator

a-sully commented Mar 9, 2022

This issue has been ported to the new spec: whatwg/fs#19

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants