GNOME Bugzilla – Bug 562976
%gconf.xml atomic update is broken
Last modified: 2008-12-08 15:42:35 UTC
Please describe the problem: If I do stuff like 'gconftool-2 --set --type=bool /apps/foo true', gconftool-2 is trying to update the '%gconf.xml' file atomically. Namely, it creates a temporary '%gconf.xml.new' file, puts the new contents there, then moves '%gconf.xml.new' to '%gconf.xml'. The idea is right, however the implementation is buggy, because '%gconf.xml.new' is not synchronized before the rename. This means that if power cut happens after re-name, we end up with corrupted '%gconf.xml' anyway. We actually observe this at our ARM-based device. I think you should just add a 'sync(fd)' call before closing 'tmpfile' in the 'logfile_save()' function (I found it in gconf/gconfd.c). Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Note, we use UBIFS and here is some documentation about how to use synchronization properly, which applies to any Linux FS, not just UBIFS: http://www.linux-mtd.infradead.org/doc/ubifs.html#L_writeback
Do you have a tested patch for this issue? I assume it's something along the lines of: goto out; } + if (fdatasync (fd) < 0) + { + gconf_log (GCL_WARNING, + _("Could not flush saved state file '%s' to disk: %s"), + tmpfile, g_strerror (errno)); + } + if (close (fd) < 0) {
Looks right to me.
Err, no, I do not have a patch. I just noticed the bug and hoped you guys would fix it.
I don't have an environment set up with ubifs to test this. I was hoping you already had a patch in your internal builds that has already been vetted. If not, we can commit the above.
commited
Well, other guys are doing gconf fixes, and we could wait and I could take the patch when they do it and test it. But their patch is the same anyway. Thank you for the fix.
Created attachment 123861 [details] [review] Sync when saving data as well The real cause of issues is when saving the data, not the log file. Attached equally untested patch that syncs the data in the markup backend.
Well, I guess the log file fix does not hurt anyway.
ah, that makes a lot more sense to me. Can one of you guys test that patch and say if it actually fixes the issue?
Richard Hult has reported in our internal bugzilla that his patch fixes the problem with corrupted gconf files for our platform.
Sounds good.
Commited this with a two small changes 1) fflush() the FILE stream before syncing 2) Use fsync instead of fdatasync (see bug 563401)