should be clear how API users can save without risk of corruption from partially completed writes #48
Milestone
Comments
mkruisselbrink
added a commit
that referenced
this issue
May 15, 2019
This attempts to solve #37 by making it explicit that changes made to files might not be reflected on disk until flush() or close() is called on the writer. This also introduces a "atomic" mode for FileSystemWriter where any changes are written to a temporary file, and only on flush or close is that file moved on top of the destination file. This should address #48.
|
Thanks for the feedback. I agree that this is an important use case that isn't sufficiently addressed. I create #51 with one possible solution for this. |
mkruisselbrink
added a commit
that referenced
this issue
Jun 10, 2019
This attempts to solve #37 by making it explicit that changes made to files might not be reflected on disk until flush() or close() is called on the writer. This also introduces a "atomic" mode for FileSystemWriter where any changes are written to a temporary file, and only on flush or close is that file moved on top of the destination file. This should address #48.
mkruisselbrink
added a commit
that referenced
this issue
Jun 10, 2019
* Add options to createWriter() to deal with atomic writes. This attempts to solve #37 by making it explicit that changes made to files might not be reflected on disk until close() is called on the writer. This also introduces a "atomic" mode for FileSystemWriter where any changes are written to a temporary file, and only on close is that file moved on top of the destination file. This should address #48.
|
@dbaron thank you very much for bringing up this important problem! I think that #51 solves it. The new default mode of operation is that files are written to a temporary location, and are atomically renamed into their final destination when the writer is closed. Please open new issues if you see more opportunities for improvement! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
(Sorry, I think there's a bunch of terminology for this stuff that I think I used to know, but can't currently remember. So I'm just describing the concepts without using the commonly-used names for them!)
When writing to files (e.g., for "save" functionality for documents, or for important configuration files), it's important not to overwrite a correct and complete copy of the file with a partial one, e.g., if the application crashes or the system loses power during the write. So in many cases when writing to files, software will write to a separate temporary file, and then once that write has completed, replace the intended destination file with the temporary. There are also more advanced ways of achieving the same goal.
The important piece is that if the use case is opening and later saving files, being able to do this with high reliability quickly becomes an important piece of it.
If this specification is going to advance, I think it should be clear what the path to achieving it in this model is. It might be that the browser plays a significant role in doing this (likely preferable), or it might be that the API simply lets the application do it. (However, if it does... the API needs to be structured in a way that doing it doesn't require any extra permission grants from the user, no matter what permission model the browser chooses to use, which seems like it might be a problem!)
So at the least I think the explainer should give examples of how to do this, and it seems like it might require changes in the feature set in the spec to handle this use case.
(Note that I got here from mozilla/standards-positions#154.)
The text was updated successfully, but these errors were encountered: