[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: ktempfile
From:       "Jos Poortvliet" <jospoortvliet () gmail ! com>
Date:       2007-10-17 18:49:45
Message-ID: 5c77e14b0710171149x7df2bbbcr7b82212c1a7f7905 () mail ! gmail ! com
[Download RAW message or body]

On 10/17/07, Oswald Buddenhagen <ossi@kde.org> wrote:
> On Wed, Oct 17, 2007 at 06:52:55PM +0200, Lubos Lunak wrote:
> >  Thinking of this, how should this actually happen, in practice? Config files
> > are written first to a temporary file and this file gets renamed to the
> > original name, atomically replacing the old file. How exactly should it
> > happen that the original file gets destroyed but the new file doesn't manage
> > to replace it properly?
> >
> the metadata is safe. but the contents of the new file might not be on
> disk yet. XFS is/was particularly susceptible to this type of data loss.
> so fdatasync() is indeed the solution.

So a file gets written to temp, then its copied over the old file. Now
if a hang occurs, either the file is copied, or not copied, right? So
worst case is: the file is NOT copied, and the old settings are kept
intact. I mean, if a crash happens during the copying (which could
happen anyway) the journal should be replayed or something. Sync
doesn't really help here.

Now how bad is it if a change isn't saved? I mean, is it
life-threatening, or would the user accept the crash did something bad
(file not saved)? I would personally accept not saving the new
settings if they where done shortly before a crash. Are there
horror-scenario's with that?

> probably, one should analyse how things look over nfs. not that i expect
> any problems with nfs >= 3.
>
> --
> Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
> --
> Chaos, panic, and disorder - my work here is done.
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
>
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]