GNOME Bugzilla – Bug 723003
gsettings list-recursively reports some keys multiple times
Last modified: 2018-04-12 00:05:28 UTC
list-recursively reports most (though not all) keys multiple times, e.g.: org.gnome.gedit.state.window bottom-panel-active-page 0 org.gnome.gedit.state.window bottom-panel-active-page 0 org.gnome.gedit.state.window bottom-panel-active-page 0 Might be because it recurses on org.gnome.gedit, then on org.gnome.gedit.state and then on org.gnome.gedit.state.window, reporting this key thrice. Original report: http://bugs.debian.org/730799
This is because the schema is listed as both a child (from the parent), but is given a precise path (from the child). It therefore gets a visit as part of the enumeration of the parent, as well as its own visit. This wasn't meant to be how this feature is used, but clearly some people are using it that way.
Two possible fixes here: 1) add a warning to the schema compiler about this behaviour [as should have existed in the first place] and hope that people slowly fix the issue; or 2) make 'gsettings list-recursively' smarter about not revisiting paths multiple times. this would be pretty easy: just build a hash table of paths that we've already visited.
I would suggest doing both.
3) if 'gsettings list-recursively' is run with no specific schemaid and it encounters a child which has its own path specified, then don't iterate it, knowing that it will be handled on its own from the toplevel elsewhere
Created attachment 367810 [details] [review] gsettings: remove redundancy in 'list-recursive'
I think there's actually no reason to forbid people from having child relationships to schemas that have their own path (when said settings will always be at only this one path). This might not have been the intended use case, but there's also nothing wrong with it. On one hand, having the fixed path for a given schema can be useful (to directly instantiate it), and having the child relationship can also be useful (to use get_child()). Even if these are two separate ways of doing the same thing, there is no real problem with a given schema supporting them both. I'm also not super keen on adding a new warning to the schema compiler that will annoy a bunch of people for little gain. Let's just go with this.
Review of attachment 367810 [details] [review]: Might be good to clarify in the commit message that while this use of child schemas is ‘odd’, you’ve decided it’s correct and supported. ::: gio/gsettings-tool.c @@ +282,3 @@ + + if (will_see_elsewhere) + continue; Isn’t `child` leaked on this continue path?
Review of attachment 367810 [details] [review]: ::: gio/gsettings-tool.c @@ +282,3 @@ + + if (will_see_elsewhere) + continue; This is correct. My clever use of a variable to avoid leaking the schema has failed to save me here. grr.
Created attachment 367811 [details] [review] gsettings: remove redundancy in 'list-recursive'
Review of attachment 367811 [details] [review]: ++
Attachment 367811 [details] pushed as 235f495 - gsettings: remove redundancy in 'list-recursive'
2.56.0 (which has 235f495 according to its changelog) is still not fixed: cventin:~> gsettings list-recursively | grep org.gnome.evolution.window org.gnome.evolution.window width 0 org.gnome.evolution.window maximized false org.gnome.evolution.window height 0 org.gnome.evolution.window x 0 org.gnome.evolution.window y 0 org.gnome.evolution.window width 0 org.gnome.evolution.window maximized false org.gnome.evolution.window height 0 org.gnome.evolution.window x 0 org.gnome.evolution.window y 0 org.gnome.evolution.window width 0 org.gnome.evolution.window maximized false org.gnome.evolution.window height 0 org.gnome.evolution.window x 0 org.gnome.evolution.window y 0 org.gnome.evolution.window width 0 org.gnome.evolution.window maximized false org.gnome.evolution.window height 0 org.gnome.evolution.window x 0 org.gnome.evolution.window y 0 org.gnome.evolution.window width 0 org.gnome.evolution.window maximized false org.gnome.evolution.window height 0 org.gnome.evolution.window x 0 org.gnome.evolution.window y 0 org.gnome.evolution.window width 0 org.gnome.evolution.window maximized false org.gnome.evolution.window height 0 org.gnome.evolution.window x 0 org.gnome.evolution.window y 0 org.gnome.evolution.window width 0 org.gnome.evolution.window maximized false org.gnome.evolution.window height 0 org.gnome.evolution.window x 0 org.gnome.evolution.window y 0
Are you sure those keys/values are for the same path? If I run that, I get different values for each instance of each key, which indicates to me that the keys are being listed for schema instances at different paths, which is not what this bug is about. This bug is about the keys for a single schema instance (at a single path) being listed multiple times.
I do not provide a path, i.e. I just use: gsettings list-recursively and I can see no paths printed. If the values are path-dependent, then it makes no sense to output them without the corresponding path, and there is even a loss of information (the goal is to keep some form of human-readable backup of my current config). This would be a different bug, I assume.
Yes, please file that as a separate bug report. Thanks.
Reported as bug 795179.