(prior art: #56361)
All our writes in VSCode today operate on the target file:
- truncate the file to 0 bytes
- write the contents into the file
If a crash happens after truncation, the file will remain empty. This should typically not result in dataloss because we have a backup to recover from. However, some external tools may act up when they get an event for the file being empty and in certain bad situations we still might end up with an empty file (e.g. when auto save is on where we do not backup).
An alternate strategy to ensure a file is consistent is to:
- write the contents of the editor into a temporary file
- move the file over the original one in a single atomic file operation (my understanding is that moves are atomic unless you move across disks)
While this reduces the chance of corrupt files, the downside to this approach is that some external file watchers might be confused about a file constantly being replaced and not just written to.
(prior art: #56361)
All our writes in VSCode today operate on the target file:
If a crash happens after truncation, the file will remain empty. This should typically not result in dataloss because we have a backup to recover from. However, some external tools may act up when they get an event for the file being empty and in certain bad situations we still might end up with an empty file (e.g. when auto save is on where we do not backup).
An alternate strategy to ensure a file is consistent is to:
While this reduces the chance of corrupt files, the downside to this approach is that some external file watchers might be confused about a file constantly being replaced and not just written to.