Which d conf

The dconf system now allows individual settings or entire settings subpaths to be locked down to prevent user customization. For more information on how to lock settings, see Section 9. Using the dconf utility on home directories shared over NFS requires additional configuration. See Section 9. See Chapter 9, Configuring Desktop with GSettings and dconf for more information on using GSettings and dconf to configure user settings.

Documentation A system administrators guide for dconf is available. The dconf API is very simple and small.

It can be roughly divided into 4 categories: utility functions database read functions database write functions watching The read functions allow you to list the contents of the database, to read values, and to query the writability of a particular portion of the database ie: according to system policy. Due to the database being mapped into each process's address space, these calls are synchronous and non-blocking. The write functions allow you to set keys including atomic multi-key writes , to reset keys and to apply locks ie: policy.

These calls all exist in two flavours: blocking synchronous versions and non-blocking asynchronous versions with an API style similar to that used in GIO. The watching functions allow you to express interest in modifications to certain portions of the tree or single keys.

Note: Most applications will not want to interface directly with dconf, but rather with GSettings. Hosted by Red Hat.

The binary file for the defaults can optionally be compiled from a set of plain text keyfiles. 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.

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. 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 ms. 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.

The binary database format that dconf uses by default is not suitable for use on NFS, where mmap does not work well.