This issue was initially posted in https://github.com/WICG/file-system-access/issues/236, then migrated over to this spec as #19, which lumped the autoClose flag's proposal with some other proposals about file locking. Those file locking discussions are now taking place on #34, #19 has since been closed and this issue will track the autoClose feature in particular.
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.
This issue was initially posted in https://github.com/WICG/file-system-access/issues/236, then migrated over to this spec as #19, which lumped the
autoCloseflag's proposal with some other proposals about file locking. Those file locking discussions are now taking place on #34, #19 has since been closed and this issue will track theautoClosefeature in particular.Here is the original description, pasted from https://github.com/WICG/file-system-access/issues/236:
@mkruisselbrink
Currently you need to explicitly close a
FileSystemWritableFileStreamfor 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
autoCloseflag 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.