Re: [Evolution] sudden loss of config

But it doesn't call fsync() or fdatasync() does it?

Just because the file is closed, doesn't mean its written to disk.  And
logging filesystems like reiserfs and ext3 only log the metadata

So ...
If your program does

The filesystem will probably have logged the metadata update to the
filesystem log, and maybe updated the directory.

However, the data underlying the file may still be sitting in the buffer
cache (depending somewhat on the os, but even AmigaOS had a 1/2 second
delay on buffer cache flushes, and DOS would only gurantee sync back at
the command prompt).

If you then lose power, or otherwise hang the kernel, that data will
never reach it to disk, and the log will also indicate this.

At restart, the log will be executed, and it will see an unfinished file
write record, and well, delete the file since it is corrupt (this my
basic understanding of how metadata-only logging filesystems work).

It'd be interesting to see if everyone with this problem is using
reiserfs, which might be more aggressive about certain buffering
operations (?).

On Wed, 2002-07-10 at 05:58, Jeffrey Stedfast wrote:
I've just looked into how bonobo-conf saves the xml config options and
it first saves the settings to a tmp file, if that works, then it
rename()'s it to ~/evolution/config.xmldb so afaict, the only way for
the settings to be corrupt in ~/evoltion/config.xmldb is if libxml's
xmlSaveFile() says that it worked when it didn't (and that would not be
our problem - the only way to get this fixed is to put pressure on the
libxml maintainer because he won't listen to us).


On Tue, 2002-07-09 at 15:58, Michael Gruner wrote:
wait until the annoying "Evolution is closing" dialog to disappear, if
it is still up then your data might not have been written to disk yet.
I'm really sure I did.

Anyway in the future I'll try to give evo some extratime to work around

thank you all for your help!


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