The LFSH and XDG Basedir disagree on the meaning of $XDG_STATE_HOME in a way that can result in issues such as data loss.
The XDG Base Directory's view of $XDG_STATE_HOME
Versions 0.6 and 0.7 of the XDG Base Directory specification did not include $XDG_STATE_HOME.
In version 0.8 (the latest version), it includes the following definition (emphasis mine):
The $XDG_STATE_HOME contains state data that should persist between (application) restarts, but that is not important or portable enough to the user that it should be stored in $XDG_DATA_HOME. It may contain:
actions history (logs, history, recently used files, …)
current state of the application that can be reused on a restart (view, layout, open files, undo history, …)
LFSH
The UAPI.9 Linux File System Hierarchy includes the following analogy:
/var/lib/package/ Persistent private data of the package. This is the primary place to put persistent data that does not fall into the other categories listed. Packages should be able to create the necessary subdirectories in this tree on their own, since the directory might be missing on boot. To create an empty directory, a tmpfiles.d(5) fragment or the StateDirectory= directive of service units (see systemd.unit(5)) may be used.
~/.local/state/package/ Persistent state data of the package.
The ~/.local/share directory is not even mentioned in the table section.
The issue
The UAPI spec encourages the use of $XDG_STATE_HOME as the default choice for packages to write all forms of mutable state, with $XDG_DATA_HOME relegated to a separate specification.
However, a system utility that follows the XDG Base Directory Specification does not think $XDG_STATE_HOME is used for all state, instead it believes that applications will use $XDG_DATA_HOME to store important data and use $XDG_STATE_HOME for "unimportant" data such as logs, history, current window positions, etc.
One could imagine a filesystem cleanup utility recommending the deletion of large files and directories under ~/.local/state, as such a cleaning program believes (correctly according to the XDG Basedir Spec) that those files can be deleted without important data being lost.
The redefinition of $XDG_STATE_HOME also loses one of the benefits of the XDG Base Directory Specification: efficient backups.
Each directory has a clean mapping to how one would backup a user's persistent data:
$XDG_CONFIG_HOME should be backed up, and possibly shared across systems for provisioning$XDG_DATA_HOME should also be backed up$XDG_STATE_HOME does not need to be backed up
If every user application puts all of its state data into $XDG_STATE_HOME, then this recommendation would need to change.
Remedy
I believe the UAPI specification should include a warning that its use of $XDG_STATE_HOME is intentionally different and incompatible with that of the XDG Base Directory Specification.
It should also include the ~/.local/share directory in the comparison table.
It should also come up with a solution to the issue with backups I mentioned.
I don't have a solution to this problem though.
The LFSH and XDG Basedir disagree on the meaning of
$XDG_STATE_HOMEin a way that can result in issues such as data loss.The XDG Base Directory's view of
$XDG_STATE_HOMEVersions 0.6 and 0.7 of the XDG Base Directory specification did not include
$XDG_STATE_HOME.In version 0.8 (the latest version), it includes the following definition (emphasis mine):
LFSH
The UAPI.9 Linux File System Hierarchy includes the following analogy:
The ~/.local/share directory is not even mentioned in the table section.
The issue
The UAPI spec encourages the use of
$XDG_STATE_HOMEas the default choice for packages to write all forms of mutable state, with$XDG_DATA_HOMErelegated to a separate specification.However, a system utility that follows the XDG Base Directory Specification does not think
$XDG_STATE_HOMEis used for all state, instead it believes that applications will use$XDG_DATA_HOMEto store important data and use$XDG_STATE_HOMEfor "unimportant" data such as logs, history, current window positions, etc.One could imagine a filesystem cleanup utility recommending the deletion of large files and directories under
~/.local/state, as such a cleaning program believes (correctly according to the XDG Basedir Spec) that those files can be deleted without important data being lost.The redefinition of
$XDG_STATE_HOMEalso loses one of the benefits of the XDG Base Directory Specification: efficient backups.Each directory has a clean mapping to how one would backup a user's persistent data:
$XDG_CONFIG_HOMEshould be backed up, and possibly shared across systems for provisioning$XDG_DATA_HOMEshould also be backed up$XDG_STATE_HOMEdoes not need to be backed upIf every user application puts all of its state data into
$XDG_STATE_HOME, then this recommendation would need to change.Remedy
I believe the UAPI specification should include a warning that its use of
$XDG_STATE_HOMEis intentionally different and incompatible with that of the XDG Base Directory Specification.It should also include the
~/.local/sharedirectory in the comparison table.It should also come up with a solution to the issue with backups I mentioned.
I don't have a solution to this problem though.