This file is indexed.

/usr/share/gtk-doc/html/dconf/dconf-overview.html is in libdconf-doc 0.26.0-2.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>dconf: dconf Reference Manual</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.79.1">
<link rel="home" href="index.html" title="dconf Reference Manual">
<link rel="up" href="index.html" title="dconf Reference Manual">
<link rel="prev" href="index.html" title="dconf Reference Manual">
<link rel="next" href="ch01.html" title="DConf Client API">
<meta name="generator" content="GTK-Doc V1.25 (XML mode)">
<link rel="stylesheet" href="style.css" type="text/css">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<table class="navigation" id="top" width="100%" summary="Navigation header" cellpadding="2" cellspacing="5"><tr valign="middle">
<td width="100%" align="left" class="shortcuts"></td>
<td><a accesskey="h" href="index.html"><img src="home.png" width="16" height="16" border="0" alt="Home"></a></td>
<td><img src="up-insensitive.png" width="16" height="16" border="0"></td>
<td><a accesskey="p" href="index.html"><img src="left.png" width="16" height="16" border="0" alt="Prev"></a></td>
<td><a accesskey="n" href="ch01.html"><img src="right.png" width="16" height="16" border="0" alt="Next"></a></td>
</tr></table>
<div class="refentry">
<a name="dconf-overview"></a><div class="titlepage"></div>
<div class="refnamediv"><table width="100%"><tr>
<td valign="top">
<h2><span class="refentrytitle">dconf</span></h2>
<p>dconf — A configuration systen</p>
</td>
<td class="gallery_image" valign="top" align="right"></td>
</tr></table></div>
<div class="refsect1">
<a name="id-1.2.4"></a><h2>Description</h2>
<p>
      dconf is a simple key/value storage system that is heavily optimised for reading.  This makes it an ideal
      system for storing user preferences (which are read 1000s of times for each time the user changes one).
      It was created with this usecase in mind.
    </p>
<p>
      All preferences are stored in a single large binary file.  Layering of preferences is possible using
      multiple files (ie: for site defaults).  Lock-down is also supported.  The binary file for the defaults
      can optionally be compiled from a set of plain text keyfiles.
    </p>
<p>
      dconf has a partial client/server architecture.  It uses D-Bus.  The server is only involved in writes
      (and is not activated in the user session until the user modifies a preference).  The service is stateless
      and can exit freely at any time (and is therefore robust against crashes).  The list of paths that each
      process is watching is stored within the D-Bus daemon itself (as D-Bus signal match rules).
    </p>
<p>
      Reads are performed by direct access (via mmap) to the on-disk database which is essentially a hashtable.
      For this reason, dconf reads typically involve zero system calls and are comparable to a hashtable lookup
      in terms of speed.  Practically speaking, in simple non-layered setups, dconf is less than 10 times slower
      than GHashTable.
    </p>
<p>
      Writes are assumed only to happen in response to explicit user interaction (like clicking on a checkbox in
      a preferences dialog) and are therefore not optimised at all.  On some file systems, dconf-service will
      call fsync() for every write, which can introduce a latency of up to 100ms.  This latency is hidden by the
      client libraries through a clever "fast" mechanism that records the outstanding changes locally (so they
      can be read back immediately) until the service signals that a write has completed.
    </p>
<p>
      The binary database format that dconf uses by default is not suitable for use on NFS, where mmap does not
      work well. To handle this common use case, dconf can be configured to place its binary database in
      <code class="envar">XDG_RUNTIME_DIR</code> (which is guaranteed to be local, but non-persistent) and synchronize it
      with a plain text keyfile in the users home directory.
    </p>
</div>
<div class="refsect1">
<a name="id-1.2.5"></a><h2>Profiles</h2>
<p>
      A profile is a list of configuration databases that dconf consults to find the value for a key. The user's personal
      database always takes the highest priority, followed by the system databases in the order prescribed by the profile.
    </p>
<p>
      On startup, dconf consults the <code class="envar">DCONF_PROFILE</code> environment variable. If set, dconf will attempt to open
      the named profile, aborting if that fails. If the environment variable is not set, it will attempt to open the profile
      named "user" and if that fails, it will fall back to an internal hard-wired configuration. dconf stores its profiles
      in text files. <code class="envar">DCONF_PROFILE</code> can specify a relative path to a file in <code class="filename">/etc/dconf/profile/</code>,
      or an absolute path (such as in a user's home directory). The profile name can only use alphanumeric characters or '_'.
    </p>
<p>
      A profile file might look like the following:
      </p>
<pre class="screen">
user-db:user
system-db:local
system-db:site
      </pre>
<p>
    </p>
<p>
      Each line in a profile specifies one dconf database. The first line indicates the database used to write changes, and the
      remaining lines indicate read-only databases. (The first line should specify a user-db or service-db, so that users can actually
      make configuration changes.)
    </p>
<p>
      A "user-db" line specifies a user database. These databases are found in <code class="filename"><code class="envar">$XDG_CONFIG_HOME</code>/dconf/</code>.
      The name of the file to open in that directory is exactly as it is written in the profile. This file is expected to be in the binary
      dconf database format. Note that <code class="envar">XDG_CONFIG_HOME</code> cannot be set/modified per terminal or session, because then the writer
      and reader would be working on different DBs (the writer is started by DBus and cannot see that variable).
    </p>
<p>
      A "service-db" line instructs dconf to place the binary database file for the user database in <code class="envar">XDG_RUNTIME_DIR</code>.
      Since this location is not persistent, the rest of the line instructs dconf how to store the database persistently. A typical
      line is <code class="literal">service-db:keyfile/user</code>, which tells dconf to synchronize the binary database with a plain text
      keyfile in <code class="filename"><code class="envar">$XDG_CONFIG_HOME</code>/dconf/user.txt</code>. The synchronization is bi-directional.
    </p>
<p>
      A "system-db" line specifies a system database. These databases are found in <code class="filename">/etc/dconf/db/</code>. Again, the name of
      the file to open in that directory is exactly as it is written in the profile and the file is expected to be in the dconf database
      format.
    </p>
<p>
      If the <code class="envar">DCONF_PROFILE</code> environment variable is unset and the "user" profile can not be opened, then the effect is as if
      the profile was specified by this file:
      </p>
<pre class="screen">
user-db:user
      </pre>
<p>
      That is, the user's personal database is consulted and there are no system settings.
    </p>
</div>
<div class="refsect1">
<a name="id-1.2.6"></a><h2>Key Files</h2>
<p>
      To facilitate system configuration with a text editor, dconf can populate databases from plain text keyfiles. For any given system
      database, keyfiles can be placed into the <code class="filename">/etc/dconf/db/<em class="replaceable"><code>database</code></em>.d/</code> directory. The
      keyfiles contain groups of settings as follows:
     </p>
<pre class="screen">
# Some useful default settings for our site

[system/proxy/http]
host='172.16.0.1'
enabled=true

[org/gnome/desktop/background]
picture-uri='file:///usr/local/rupert-corp/company-wallpaper.jpeg'
     </pre>
<p>
      After changing keyfiles, the database needs to be updated with the
      <span class="citerefentry"><span class="refentrytitle">dconf</span>(1)</span> tool.
    </p>
</div>
<div class="refsect1">
<a name="id-1.2.7"></a><h2>Locks</h2>
<p>
      System databases can contain 'locks' for keys. If a lock for a particular key or subpath is installed into a database
      then no database listed above that one in the profile will be able to modify any of the affected settings. This can be
      used to enforce mandatory settings.
    </p>
<p>
      To add locks to a database, place text files in the <code class="filename">/etc/dconf/db/<em class="replaceable"><code>database</code></em>.d/locks</code>
      directory, where <em class="replaceable"><code>database</code></em> is the name of a system database, as specified in the profile. The files
      contain list of keys to lock, on per line. Lines starting with a # are ignored. Here is an example:
    </p>
<pre class="screen">
# prevent changes to the company wallpaper
/org/gnome/desktop/background/picture-uri
    </pre>
<p>
      After changing locks, the database needs to be updated with the
      <span class="citerefentry"><span class="refentrytitle">dconf</span>(1)</span> tool.
    </p>
</div>
<div class="refsect1">
<a name="id-1.2.8"></a><h2>Portability</h2>
<p>
      dconf mostly targets Free Software operating systems.  It will theoretically run on Mac OS but there isn't
      much point to that (since Mac OS applications want to store preferences in plist files).  It is not
      possible to use dconf on Windows because of the inability to rename over a file that's still in use (which
      is what the dconf-service does on every write).
    </p>
</div>
<div class="refsect1">
<a name="id-1.2.9"></a><h2>API stability</h2>
<p>
      The dconf API is not particularly friendly, and is not guaranteed to be stable.  Because of this and the
      lack of portability, you almost certainly want to use some sort of wrapper API around it.  The wrapper API
      used by GTK+ and GNOME applications is
      <a class="ulink" href="http://developer.gnome.org/gio/stable/GSettings.html" target="_top">GSettings</a>, which is included as
      part of GLib. GSettings has backends for Windows (using the registry) and Mac OS (using property lists) as
      well as its dconf backend and is the proper API to use for graphical applications.
    </p>
</div>
<div class="refsect1">
<a name="id-1.2.10"></a><h2>See Also</h2>
<p>
      <span class="citerefentry"><span class="refentrytitle">dconf-service</span>(1)</span>,
      <span class="citerefentry"><span class="refentrytitle">dconf-editor</span>(1)</span>,
      <span class="citerefentry"><span class="refentrytitle">dconf</span>(1)</span>,
      <a class="ulink" href="http://developer.gnome.org/gio/stable/GSettings.html" target="_top">GSettings</a>
    </p>
</div>
</div>
<div class="footer">
<hr>Generated by GTK-Doc V1.25</div>
</body>
</html>