1DCONF(7)                 Conventions and miscellaneous                DCONF(7)
2
3
4

NAME

6       dconf - A configuration system
7

DESCRIPTION

9       dconf is a simple key/value storage system that is heavily optimised
10       for reading. This makes it an ideal system for storing user preferences
11       (which are read 1000s of times for each time the user changes one). It
12       was created with this usecase in mind.
13
14       All preferences are stored in a single large binary file. Layering of
15       preferences is possible using multiple files (ie: for site defaults).
16       Lock-down is also supported. The binary file for the defaults can
17       optionally be compiled from a set of plain text keyfiles.
18
19       dconf has a partial client/server architecture. It uses D-Bus. The
20       server is only involved in writes (and is not activated in the user
21       session until the user modifies a preference). The service is stateless
22       and can exit freely at any time (and is therefore robust against
23       crashes). The list of paths that each process is watching is stored
24       within the D-Bus daemon itself (as D-Bus signal match rules).
25
26       Reads are performed by direct access (via mmap) to the on-disk database
27       which is essentially a hashtable. For this reason, dconf reads
28       typically involve zero system calls and are comparable to a hashtable
29       lookup in terms of speed. Practically speaking, in simple non-layered
30       setups, dconf is less than 10 times slower than GHashTable.
31
32       Writes are assumed only to happen in response to explicit user
33       interaction (like clicking on a checkbox in a preferences dialog) and
34       are therefore not optimised at all. On some file systems, dconf-service
35       will call fsync() for every write, which can introduce a latency of up
36       to 100ms. This latency is hidden by the client libraries through a
37       clever "fast" mechanism that records the outstanding changes locally
38       (so they can be read back immediately) until the service signals that a
39       write has completed.
40
41       The binary database format that dconf uses by default is not suitable
42       for use on NFS, where mmap does not work well. To handle this common
43       use case, dconf can be configured to place its binary database in
44       XDG_RUNTIME_DIR (which is guaranteed to be local, but non-persistent)
45       and synchronize it with a plain text keyfile in the users home
46       directory.
47

PROFILES

49       A profile is a list of configuration databases that dconf consults to
50       find the value for a key. The user's personal database always takes the
51       highest priority, followed by the system databases in the order
52       prescribed by the profile.
53
54       On startup, dconf consults the DCONF_PROFILE environment variable. If
55       set, dconf will attempt to open the named profile, aborting if that
56       fails. If the environment variable is not set, it will attempt to open
57       the profile named "user" and if that fails, it will fall back to an
58       internal hard-wired configuration. dconf stores its profiles in text
59       files.  DCONF_PROFILE can specify a rela