[Monodevelop-devel] Atomic file write API
taktaktaktaktaktaktaktaktaktak at gmail.com
Mon Mar 16 08:52:16 EDT 2009
> An issue that has recently gained prominence is reliability of file
> writes on Ext4:
> After writing a changed file to disk and the system crashes before the
> changes are flushed from the OS or disk buffers, files can be left in
> a corrupted state.
I largely agree with Matthew Garrett's POV on these matters.
> The MonoDevelop.Projects TextFile API, in addition to (partially)
> handling file encoding detection, has a file save API that attempts to
> solve this problem by writing the new file contents to a temp file and
> then using a POSIX call to rename the changed file over the old one.
> Unfortunately, I often see code in MD that doesn't use this API.
> Indeed, it's impossible to use it from MonoDevelop.Core, so I had to
> replicate the functionality there some time ago.
> Worse, as described in the posts linked above, this sequence of
> operations isn't guaranteed to be safe on POSIX.
Fortunately, it looks like at least the fsync() requirement has
already been removed for ext4 (
> I think we should add an FileStream-based API to MonoDevelop.Core for
> handling this, with several other features:
> * Levels of reliability: fsync, renaming, unsafe
> * Option to create backup files, with automatic fallbacks to backups
> when loading damaged settings files
> * Autosave to temp files, and prompting the user for recovery of
> autosaved or damaged files after a crash
Would anyone ever explicitly choose less than the most-reliable option?
The backup from temp files is nice.
> Another advantage of having this code in a centralised location is
> that it would be easy to use alternatives as they become available,
> e.g. transactional NTFS on Windows Vista
Shouldn't some of this be pushed down into the mono framework?
Obviously, stuff like restoring from backups is out-of-spec and must
be external, but shouldn't POSIX minutiae be handled by the System.IO
More information about the Monodevelop-devel-list