On Windows and Linux systems an accidental power loss could cause a recently written file to be corrupted with junk or null bytes (very often when running inside non-Hyper-V VMs which would otherwise have aligned the .vhdx with the physical storage and would flush all the way through; less often on the physical disk but there too; for example corruption happened very often with .vmdks on VMware on Windows, especially to database files).
Some critical Linux services create many backups for the settings file. Like the iSCSI target (LIO) management library rtslib which creates 10 backups for the /etc/target/saveconfig.json (not sure if this helps if someone edits 11 times in fast succession though).
While iOS devices do a clean shutdown when the battery is almost depleted there are still scenarios where accidental power loss can happen: like freezing temperatures which cause the battery to suddenly and unexpectedly lose too much amperage (an aluminium iPhone in freezing wind would die pretty fast under use, or even while idling)
I have a similar situation where a particular settings file is critical in an iOS app.
Do FileHandle.close() or Data.write(options: .atomic) on Swift iOS also flush to disk immediately?
If so, does the atomic write flush? Is it before the rename or after?
Should I avoid String.data.write()?
Is a FileHandle.synchronize() still necessary on iOS (after String.data.write) to make sure cached data has been written to storage?
After String.data.write() has completed would opening a file handle to the same file and calling FileHandle.synchronize() cause the previously written data to sync? Or is it already synced?
Various documentation comments I’ve stumbled upon in the Swift source code on GitHub (I’m currently on an iPad) also do not indicate any kind of dirty buffer syncing. Gonna do things the old fashioned way until things become clearer.
Perhaps a .synchronize option for the .write() function is something we’re gonna get in the future.