Re: Safe file update library ready (sort of)
On Sat, Jan 29, 2011 at 1:53 PM, Ted Ts'o <email@example.com> wrote:
> On Fri, Jan 28, 2011 at 07:37:02AM +0100, Olaf van der Spek wrote:
>> Is there a way to log cases where (potentially) unsafe writes happen?
>> Cases like truncation of an existing file, rename on a target that's
>> not yet synced, etc.
> Not really, because there are plenty of cases where it's perfectly OK
> not to sync a file on close or on rename. Any files created during a
> build, for example, can easily be reproduced in the unlikely case of a
> systme crash. If you are untaring a source tree, it's fine not to
> worry about syncing out the files, since presumably you can always
> repeat the untar operation. Or take git; when git is checking out
> files into the working directory, there's no reason that has to be
> done in a super-safe way. On the other hand, when it is writing the
> git object files and pack files, those had better be done safely. At
> the end of the day the application programmer needs to understand what
> is going on, and write his code appropriately based on the needs of
> his application with respect to reliability after a power crash.
> So how can you just log warnings that the program has just done
> something unsafe? It's unsafe only if there's no other way to
> reconstitute the data that was just written. But that's not something
> which is easily knowable.
If all potentially unsafe cases could be logged, the log can be
analyzed by a human to detect the real unsafe cases such that the
developers of those apps can be notified and the apps can be fixed.