[systemd-devel] file-hierarchy. user persistent data dir.
lennart at poettering.net
Fri Jul 4 03:33:06 PDT 2014
On Fri, 04.07.14 11:38, Ivan Romanov (drizt at land.ru) wrote:
> Now specification defines system variable persistent data dir (/var) but not
> defines similar directory for user data. I developer of Psi+ (IM client) when
> I was implementing XDG Base Directory Specification was questions where should
> be saved user conversation history. How I understand ~/.config is used for any
> settings of application, ~/.local/share is analogue of /usr/share, ~/.cache
> for data which always can be regenerated and can be freely removed. So no one
> from these dirs is not suitable for saving user data which is generating by
> application and needest only in this application on this machine (user
> conversation history for example).
> So I would like to see Persistent Variable User Data Directory in
I have discussed this a couple of times with various people from GNOME,
XDG and otherwise, and we came to the conclusion to avoid this
distinction between configuration and state for the user, and simply ask
applications to put both into ~/.config. Which is actually what
file-hierarchy(7) even says.
The rationale is that the distinction is too specialized for
applications, they never got that right, and since we cannot protect
this anyway we probably shouldn't simplify things here, and tell app
developers to put whatever they like that is variable and changing in
that directory. So there are there dirs:
~/.config: state and configuration, the counterpart for both /etc/ *and*
/var/lib/ in the home directory
~/.local: static vendor resources of additional packages installed into
the home directory. Should be considered read-only except when
new packages are installed or removed from the home
directory. The counterpart of /usr/ in the home directory.
~/.cache: unessential state, that can be flushed if the user desires so
without ill effect. The cunterpart of /var/cache in the home
Also see the discussion around this:
Not of course, that this is not what many apps do. Because the XDG
basedir spec is badly writtem and more confusing than explaining, what
people ultimately did is use ~/.local for state. I can only recomend not
to do that though.
We are working on making user app sandboxing work in the context of
systemd, one part of that will be that sandboxed apps will only get
write access to ~/.config and ~/.cache, but only read-only access to
~/.local, if at all.
Lennart Poettering, Red Hat
More information about the systemd-devel