The KDE File System Standard

The KDE File System Standard

Since the very beginning KDE has made use of file-hierarchy to store resources for its applications. Resources range from icons, wallpapers, fonts to sounds, menu-descriptions and configuration files.

In KDE 1 there were two locations were resources could be located: the resources provided by the system where located under $KDEDIR and user specific resources where located under $HOME/.kde.

In KDE 2 resource management has been largely abstracted by the introduction of the KStandardDirs class and has become much more flexible. The user or administrator can now specify a variable number of locations where resources can be found. A list of locations can either be specified via $KDEDIRS (notice the extra S), via /etc/kderc and even via the kdeglobals config file. The location where user specific resources can be found can be set with $KDEHOME (The default is $HOME/.kde). Changes made by the user are always written back to $KDEHOME.

Both KDE 1 and KDE 2 feature so called “cascading configuration files”: There can be multiple configuration files with the same name in the various locations for (config) resources, when that is the case, the information of all these configuration files is combined on a key by key basis. If the same key (within a certain group) is defined in more than one place, the value of the key for the config file that was read last will override any previously read values. Configuration files under $KDEHOME are always read last. This ensures that after a configuration entry is written, the same value wil be read back.

In KDE 3 two important changes have been made:

  • Default values are no longer written.

    When a configuration file in a location other than $KDEHOME defines a value for a key and the application subsequently writes out a new configuration file to $KDEHOME, that configuration file will only contain an entry for the key if its value differs from the value read from the other file.

    This counters the problem that changing default configuration files under $KDEDIR would not take effect for users, since these users would most likely have their own copy of these settings under $KDEHOME. KDE 3 will make sure not to copy these settings so changes made under $KDEDIR will affect all users that haven't explicitly changed the affected settings to something else.

  • Configuration entries can be marked “immutable”.

    Starting with KDE 3, configuration entries can be marked “immutable”. When a configuration entry is immutable it means that configurations files that are read later will not be able to override its value. Immutable entries can not be changed via KConfig and if the entry is present under $“KDEHOME” it will be ignored.

    Entries can be marked immutable on 4 different levels:

    On an entry by entry basis by appending [$i] after the key.


    On a group by group basis by appending [$i] after the group. All entries specified in the group will be marked immutable and no new entries can be added to the group


    On a file by file basis by starting the file with [$i]


    On a directory basis

    [Not yet implemented]

    The filesystem can also be used to mark files immutable. If KDE does not have write-access to the user's version of a configuration file, the file will be automatically considered immutable.


    chown root.root /home/user/.kde/share/config/kickerrc
    chmod 644 /home/user/.kde/share/config/kickerrc


    This example is not fool-proof, the user can potentially still rename either the root-owned kickerrc file or any of the directories in the path to another name and create a new kickerrc _with_ write-access.

KDE Logo