|
Size: 2726
Comment: Add previous instances of the state dir discussion/proposals
|
Size: 3456
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 45: | Line 45: |
Some questions that might help to distinguish between the different classes: || || '''DATA''' || '''CONFIG''' || '''STATE''' || '''CACHE''' || '''RUNTIME''' || || sync across machines? || yes? || yes || no || no || no || || manage in VCS (Git/SVN)?|| no || yes || no || no || no || || should be backed up? || yes || yes || yes || no || no || || can live in tmpfs? || no || no || no || yes || yes? || || contains much data? || yes || no || no || yes || no || |
The XDG Base Directory Specification (XDGBDS) defines four directories in a users $HOME dir that should be used for so called DotFiles.
These directories (with their default locations) are:
- $XDG_DATA_HOME ($HOME/.local/share): data files
- $XDG_CONFIG_HOME ($HOME/.config): configuration files
- $XDG_CACHE_HOME ($HOME/.cache): non-essential data files
- $XDG_RUNTIME_DIR (no default?): non-essential runtime files, other file objects (such as sockets, named pipes, ...)
Please refer to the specification for additional directory definitions and further details.
Tools
Status of Packages
TODO: Which packages do not conform to the XDGBDS and has a bug been filled upstream?
* mplayer: upstream bug * xmonad: upstream bug
e.g.: ZSH, gimp, ssh, gnupg, mplayer, dbus, libpurple/pidgin,
Links
Modify your application to use XDG folders - Blog post from Lionel Dricot
Fedora initiative to make packages conform to XDGBDS
Gnome Goal to conform to XDGBDS
Proposal: STATE directory
This is a recurring request/complaint (see this or this) on the xdg-freedesktop mailing list to introduce another directory for state information that does not belong in any of the existing categories (see also home-dir.proposal. Examples for this information are:
- history files of shells, repls, anything that uses libreadline
- logfiles
- state of application windows on exit
- recently opened file
- last time application was run
The above example information is not essential data. However it should still persist on reboots of the system unlike cache data that a user might consider putting in a TMPFS. On the other hand the data is rather volatile and does not make sense to be checked into a VCS. The files are also not the data files that an application works on.
Some questions that might help to distinguish between the different classes:
|
DATA |
CONFIG |
STATE |
CACHE |
RUNTIME |
sync across machines? |
yes? |
yes |
no |
no |
no |
manage in VCS (Git/SVN)? |
no |
yes |
no |
no |
no |
should be backed up? |
yes |
yes |
yes |
no |
no |
can live in tmpfs? |
no |
no |
no |
yes |
yes? |
contains much data? |
yes |
no |
no |
yes |
no |
