From kde-core-devel Wed Sep 09 20:00:57 2009 From: David Faure Date: Wed, 09 Sep 2009 20:00:57 +0000 To: kde-core-devel Subject: Re: File corruption with KSaveFile on full disk Message-Id: <200909092200.58177.faure () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=125252651204966 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).