search

WICG / file-system-access

Expose the file system on the user’s device, so Web apps can interoperate with the user’s native applications.
https://wicg.github.io/file-system-access/
Other
670 stars 66 forks source link

Add a autoClose flag to FileSystemCreateWritableOptions #236

Closed mkruisselbrink closed 2 years ago

mkruisselbrink commented 4 years ago

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.

williamiced commented 4 years ago

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?

williamiced commented 3 years ago

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 commented 2 years ago

This issue has been ported to the new spec: https://github.com/whatwg/fs/issues/19