After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 702785 - [PATCH] Unlink ~/.config/dconf/user if it appears corrupted
[PATCH] Unlink ~/.config/dconf/user if it appears corrupted
Status: RESOLVED WONTFIX
Product: dconf
Classification: Core
Component: dconf
git master
Other Linux
: Normal normal
: ---
Assigned To: dconf-maint
dconf-maint
Depends on:
Blocks:
 
 
Reported: 2013-06-21 01:26 UTC by Colin Walters
Modified: 2013-11-25 02:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
0001-Unlink-.config-dconf-user-if-it-appears-corrupted.patch (4.58 KB, patch)
2013-06-21 01:27 UTC, Colin Walters
none Details | Review
updated patch, cleaner, with syslog (2.50 KB, patch)
2013-06-21 13:43 UTC, Colin Walters
none Details | Review
Don't leak gerror if it wasn't an INVAL (2.56 KB, patch)
2013-06-21 13:55 UTC, Colin Walters
none Details | Review

Description Colin Walters 2013-06-21 01:26:37 UTC
If we're not able to read the file, presently we go into a rather
catastropic loop of continually attempting to reopen it.  Corruption
happens much more recently now from:

See https://bugzilla.gnome.org/show_bug.cgi?id=701560

There are various ways we could address this, but if the file is
missing the gvdb header, it's likely not recoverable.  So this patch
changes the user engine lookup to unlink() it, and we'll create a new
one.

A future refinement might be to detect other forms of corruption and
attempt to preserve settings from the file (fsck-like), but really all
we're solving in this first pass is cleaning up from clearly broken
gvdb databases caused by lack of fsync().

Tested in latest gnome-ostree buildmaster, and doing:
as root from a VT.
---
 engine/dconf-engine-source-user.c |    5 ++++-
 gvdb/gvdb-reader.c                |   32 ++++++++++++++++++++++++++++++++
 gvdb/gvdb-reader.h                |    4 ++++
 tests/dconf-mock-gvdb.c           |    8 ++++++++
 4 files changed, 48 insertions(+), 1 deletions(-)
Comment 1 Colin Walters 2013-06-21 01:27:13 UTC
Created attachment 247396 [details] [review]
0001-Unlink-.config-dconf-user-if-it-appears-corrupted.patch
Comment 2 Adam Williamson 2013-06-21 01:53:42 UTC
From a very quick search through the patch, it doesn't look like anything is logged when this happens. As the user experience would be something like 'all user settings suddenly and mysteriously reset to default without any obvious indication of why', would it be a good idea to at least emit a log message of some kind when this happens?
Comment 3 Colin Walters 2013-06-21 13:43:46 UTC
Created attachment 247441 [details] [review]
updated patch, cleaner, with syslog
Comment 4 Colin Walters 2013-06-21 13:55:13 UTC
Created attachment 247442 [details] [review]
Don't leak gerror if it wasn't an INVAL

Minor issue noted in self-code-review: we were leaking the gerror if the error was something other than INVAL.
Comment 5 Allison Karlitskaya (desrt) 2013-11-25 02:47:40 UTC
I think the number of users impacted by the ext4 issue was quite small in the end, and aside from that we've never had reports of corrupt dconf database.  I'd prefer to keep the failure case as explicit as possible, so let's not do this.