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 702394 - Remove from favorites doesn't work [Regression]
Remove from favorites doesn't work [Regression]
Status: RESOLVED DUPLICATE of bug 701560
Product: dconf
Classification: Core
Component: gsettings backend
0.16.x
Other Linux
: Normal normal
: ---
Assigned To: dconf-maint
dconf-maint
: 702574 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-06-16 14:01 UTC by Carlos Soriano
Modified: 2013-06-21 12:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Carlos Soriano 2013-06-16 14:01:04 UTC 
Fedora 19, gnome 3.8.3

You can try it easily removing two different items from favorites. You can see that when you try to remove the second one the first one removed is added again, and the second one is not removed. Also, gnome-shell crash after some iterations doing the same.
Comment 1 Florian Müllner 2013-06-17 09:11:58 UTC 
I cannot reproduce this. Maybe the first favorite you removed was running?
Comment 2 Carlos Soriano 2013-06-17 10:24:30 UTC 
um, strange, it is a freshly fedora 19 beta installation(updated). I ran gnome-shell from terminal and seems something related to dconf. The problem while trying to remove favorites was:

(gnome-shell:2282): dconf-WARNING **: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code17: Cannot open dconf database: invalid gvdb header

The dconf version is 0.16
Comment 3 Florian Müllner 2013-06-17 11:03:46 UTC 
Mmh, I've seen some downstream reports about dconf troubles recently. In any case, it's not a shell issue, let's move it to dconf.
Comment 4 Florian Müllner 2013-06-18 16:04:17 UTC 
*** Bug 702574 has been marked as a duplicate of this bug. ***
Comment 5 Adam Williamson 2013-06-19 01:33:28 UTC 
Yeah, I've seen several cases of user's dconf database being corrupted on IRC lately. It actually happened to me too, though that was after a hard system freeze so it could've been caused by that. I'll see if I can reproduce on a fresh install.
Comment 6 Adam Williamson 2013-06-19 17:17:15 UTC 
I couldn't reproduce this on a simple fresh F19 TC5 GNOME install in a VM, but the fact that people seem to keep popping up with corrupted dconf databases lately does worry me a bit. I'm not really sure how to investigate further without some kind of reliable reproducer, though.
Comment 7 Adam Williamson 2013-06-19 17:29:26 UTC 
Probably worth linking the downstream Fedora report we have here:

https://bugzilla.redhat.com/show_bug.cgi?id=975521
Comment 8 Adam Williamson 2013-06-19 17:36:25 UTC 
Did who's been affected by the 'corrupted file' version of this bug *not* see it after an unclean shutdown/restart?
Comment 9 Allison Karlitskaya (desrt) 2013-06-21 12:46:30 UTC 
We've been tracking this bug down the past day or so and we're pretty convinced that it's something like a bug in ext4.  I say "something like a bug" because it's unclear exactly what guarantees the filesystem provides in crash situations and the developer of the filesystem is telling a different story on the mailing list than what is in the official documentation (and we depended on a statement in the official documentation).

The real source of this bug is the changes I made in bug 701560, where there is ongoing discussion on this topic, so I'll dup this bug to that.

*** This bug has been marked as a duplicate of bug 701560 ***