[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Safe file update library ready (sort of)



On Sat, Jan 29, 2011 at 1:53 PM, Ted Ts'o <tytso@mit.edu> 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.

-- 
Olaf


Reply to: