PDA

View Full Version : [ubuntu] ~/.config/dconf/user how is it created/cobbled together?



gmoore777
April 6th, 2014, 07:05 PM
1.)
~/.config/dconf/user, is a binary file
and is the user's dconf database
where settings (or only overrides?) to your GUI environment are saved.

That I understand and am somewhat OK with.

2.)
If I remove that binary file ~/.config/dconf/user,

I do know that it will get automajically created if I run:

`gsettings set ...`
or
`sudo dconf update`

That makes sense, and am somewhat OK with that.

3.)
But I have a feeling, this file is stored in memory, (rather than
getting constructed on the fly), and then re-saved to that location.
or
I have a feeling, that there is "another" file somewhere else that has only
the dconf settings that I have personally changed myself with either
`gsettings set ...` or `dconf-editor` or
via the SystemSettings-->Brightness&Lock tab,
then ~/.config/dconf/user is constructed from that "other" small file.
(where is this "other" small file?)

4.)
I'm pulling my hair out watching the different behaviours between
`gsettings` and `dconf-editor` in regards to how they handle
whether I am attempting to provide a different site-wide dconf key value
or whether I am attempting to lock that dconf key.
(I would call it a bug, but i'll get to that later.)
And I believe if I find the application, the entity, the thing,
that is really constructing the file, ~/.config/dconf/user
I'll better be able to construct a better bug description.

5.)
And in case, you have followed all of that, one discrepancy that I have found
is that `gsettings get` will honor that you have a site-wide lock set up, but will
only display the default setting that is found in /usr/share/glib-2.0/schemas/gschemas.compiled
rather than the site-wide value that I have set up.
`dconf-editor` will honour both the lock and the new site-wide value that I have set up.

5B.)
Additionally, being a bad boy, if I edit this file, say,
/usr/share/glib-2.0/schemas/org.gnome.desktop.session.gschema.xml
and if I don't have any site-wide overrides for the key of, idle-delay,
nor a site-wide lock for that key, then,
`dconf-editor` will read (and display) the value from this XML file, rather than from
/usr/share/glib-2.0/schemas/gschemas.compiled like `gsettings get` does.
This I do NOT consider a bug as I probably would have to "recompile"
(if I knew how)
/usr/share/glib-2.0/schemas/gschemas.compiled in order to
get `gsettings set` and `dconf-editor` to be in synch with
respect to this one idiosyncracy.
But I did want to point out that `dconf-editor` has a different
pecking order to look for values than does `gsettings get`.

6.)
But let me get back to this file: ~/.config/dconf/user.
I would love to know how to destroy this file and have it not
"re-appear".
The file seems too large, 16534 bytes, for the couple
of dconf settings that I have changed.
I want to undo every `gsetting set` command and
undo every edit I did in `dconf-editor` by finding the
secret place where these changes have been stored
and destroying that file.

7.)
Where are these local/user dconf edits saved?

8.)
Or maybe I have to kill a background process that is
holding ~/.config/dconf/user in memory, then
remove ~/.config/dconf/user, then log out and then
back in again, and hope that ~/.config/dconf/user
is still gone or at least mostly empty.

gmoore777
April 10th, 2014, 11:14 PM
Note to self:
This command:
dconf reset -f /
removed more than I wanted from ~/.config/dconf/user, but it's one way to start from scratch.

I also logged this bug against about how "gsettings is ignoring my override files":
https://bugs.launchpad.net/ubuntu/+source/gsettings-desktop-schemas/+bug/1303461

mc4man
April 13th, 2014, 01:47 AM
I also logged this bug against about how "gsettings is ignoring my override files":
https://bugs.launchpad.net/ubuntu/+source/gsettings-desktop-schemas/+bug/1303461
In regards to your bug - dconf is quite specific in regards to lockfiles, in the case of your example you need to use
idle-delay=uint32 15
Please read here -
https://bugzilla.gnome.org/show_bug.cgi?id=693149

gmoore777
April 15th, 2014, 01:11 AM
Hallelujah!

To mc4man: Thank you very much for that info.

prefacing/casting my "numbers" with "uint32" does in fact solve the issue
of `gsettings get` to display my site override values and, in fact,
I can actually watch my screen go black (the screensaver), then have the lock dialog
be there so many x seconds after the screensaver kicks in, in regards to my
sitewide values.
(I had to reboot to get it to work the first time with the casting.
But then after rebooting, it seemed I didn't have to reboot (or log off)
to see further manipulations take effect. Whatever. Not that important right now.
)

[I won't mention how `dconf update` should display some warnings that
values were not cast correctly and that gsettings may have a problem
of ignoring these.]

I'll make similar comments on my bug I logged.

mc4man
April 15th, 2014, 05:18 PM
I closed your bug, you can in future do yourself > just click on the entry under "status" & change.
As far as your other questions can't help much other than a few observations

I don't believe there is any "other" small file", settings seem to be in memory somehow. (mmap is mentioned..
(there is a file in /run/user/1000/dconf/ but really is nothing
Most changes, options ect. seem to be immediately reflected in ~/.config/dconf/user, many change the file size though some don't, at least not after initial option change, ie. enable, disable, enable, ect.
(- I saw one the other day, forgot what apt, where enabling, disabling an option increased, decreased user by 8 bytes each time

Starting in 13.10 or maybe 13.04 if you log out or restart when current state is different than what is in user then user will be re-written to reflect that. Easiest test of that is to delete the ~/.config/dconf/user file then log out/restart. You'll get the exact same one on login/reboot. When happening 'naturally' there is a slightly increased time on log out.
(- there have been some times when I wanted a new default user file, in that case I delete or mv user to a .bak, then kill x. (or do the delete or mv from another install or user session.
If you make changes to a schema you should recompile to cause effect & also to ck. if change is good. An improper edit will cause schemas to be ignored
If you haven't figured out -

sudo glib-compile-schemas /usr/share/glib-2.0/schemas/
Read output carefully to make sure edit is ok, don't log out till it is (or return edit to orig. if need be