Coming back to this old thread after losing some configuration in kmail and 
plasma after a disk full situation....

On Friday 06 February 2009 20:56:39 Thiago Macieira wrote:
> Michael Pyne wrote:
> >On Friday 06 February 2009, David Faure wrote:
> >> On Tuesday 20 January 2009, Thiago Macieira wrote:
> >> > The problem with buffered mode is that write() will report that it
> >> > wrote all bytes, but the saving of them to disk might fail. In that
> >> > case, the write happens inside flush()
> >>
> >> So a solution is to test the return value of flush(), right? That's
> >> actually easier than checking each and every write() call... (and much
> >> more performant than using Unbuffered).
> >>
> >> When does flush happen if not called explicitely? In close? So we
> >> should do this?
> >
> >There's no guarantee that in buffered mode write() won't actually have
> > to write to disk though, is there? 

But that's what we want, so I don't see the problem there.

> > We know that pending changes will
> > have been written out by flush() but there's no reason that write()
> > won't actually write if its own internal buffers fill up.

That's fine. We just want to know if something fails, whether that's write() 
or flush().

> And then there's no reason that the write won't be blocked in the hard
> drive's own buffers.
> 
> There's a point where the effort becomes too great.

So you're saying we have no way to avoid losing configuration in a "disk full" 
situation !?

-- 
David Faure, faure@kde.org, sponsored by Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).