[Monodevelop-devel] Atomic file write API
m.j.hutchinson at gmail.com
Mon Mar 16 13:33:59 EDT 2009
On Mon, Mar 16, 2009 at 8:52 AM, Levi Bard
<taktaktaktaktaktaktaktaktaktak at gmail.com> wrote:
>> 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.
Me too, but that doesn't change the fact that these problems are
permitted by POSIX, so even if heuristics are added for fixed for ex4
and btrfs, which should still do the right thing in case other
filesystems are used.
>> 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?
Because it has a cost. An fsync can be very expensive. Presumably the
heuristics employed by ext4 have some associated cost too.
> 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
How could it be fixed? AFAIK the truncate-on-overwrite exists on
Windows (though not the need for fsync), which is one reason why
Transactional NTFS was added.
More information about the Monodevelop-devel-list