-
Notifications
You must be signed in to change notification settings - Fork 65
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
Comments
If a |
- 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}
Hi Marijn, do we have any progress about this issue? Chrome Camera app (one of the built-in CrOS app) is using this API. Is it possible to implement the part to make the API not writing empty file when the app is closed first? |
This issue has been ported to the new spec: whatwg/fs#19 |
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 toFileSystemCreateWritableOptions
. 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.
The text was updated successfully, but these errors were encountered: