Вопрос или проблема
Предыстория
Конвенция Unix и стандарт файловой системы Linux определяют несколько путей, по которым процессы ищут определенную информацию или используют для записи определенной информации. Когда необходимо настроить окружение, специфичное для пользователя, как пользователя без прав суперпользователя – большинство этих мест либо недоступны, либо читаемы, но без возможности записывать в файлы или создавать новые. Таким образом, нужно использовать альтернативы.
В принципе, мы могли бы рассмотреть домашнюю директорию пользователя как еще один /
; однако это не общепринятая практика.
Существует также обычай создания директории $HOME/.my_app
. Большинство приложений, которые создают такие директории, используют их для конфигурации, но некоторые также для других видов данных (например, Eclipse, Firefox, Thunderbird прячут там много данных). Но это означает, что у нас может быть десятки, если не сотни .что-то
в домашней директории, что довольно неприглядно.
Наконец, стало также общепринятым, что некоторые приложения записывают данные в $HOME/.local
и $HOME/.config
, что не “загромождает” саму домашнюю директорию: $HOME/.config
можно рассматривать как эквивалент /etc
, а $HOME/.local
как /usr
; это довольно полезно, но – это не охватывает /var
и его подкаталоги.
Актуальный вопрос
Где, в домашней директории пользователя, мы или программа, которую мы пишем, должны хранить данные, которые системная программа бы сохранила в /var
или подкаталогах /var
? То есть: “файлы, содержание которых ожидается как постоянно изменяемое в процессе нормальной работы системы, такие как журналы [и] спул… файлы” (цитата из FHS), а также кэш, нестатические базы данных, файлы блокировки, файлы выполнения и файлы журналов?
Я думаю, что ближайший эквивалент – это $XDG_STATE_HOME
:
$XDG_STATE_HOME
определяет базовую директорию, относительно которой должны храниться файлы состояния, специфичные для пользователя. Если$XDG_STATE_HOME
не установлен или пуст, следует использовать значение по умолчанию, равное$HOME/.local/state
.Директория
$XDG_STATE_HOME
содержит данные состояния, которые должны сохраняться между (приложенческими) перезапусками, но которые не важны или недостаточно портативны для пользователя, чтобы их следовало хранить в$XDG_DATA_HOME
. Она может содержать:
- историю действий (журналы, история, недавно использованные файлы и т. д.)
- текущее состояние приложения, которое может быть использовано при перезапуске (представление, макет, открытые файлы, история отмены и т. д.)
/var, однако, не вписываются в вышеуказанное или не очень хорошо подходят. Например, для /var/tmp
нет настоящего эквивалента $HOME
, но всем пользователям должно быть разрешено писать в /var/tmp
. В качестве еще одного примера, данные, которые должны попадать в /var/cache
при записи “системными” приложениями, на самом деле должны попадать в $XDG_CACHE_HOME
($HOME/.cache
) при записи пользовательскими приложениями.
Ответ или решение
Вопрос, касающийся того, куда программы, запущенные от имени непользователя (non-root user), должны сохранять данные, которые обычно сохраняются в системных каталогах, таких как /var
, требует понимания стандартов, установленных для файловых систем Unix и Linux. Ключевым аспектом здесь является поиск решения, которое позволит избежать «загромождения» личной директории пользователя, сохраняя при этом функциональность и производительность приложений.
Основные моменты
В Unix-подобных системах каталог /var
традиционно используется для хранения изменяемых данных, таких как логи, временные файлы и кэш. Однако, такие каталоги как /var/log
, /var/tmp
и /var/cache
нельзя использовать без соответствующих прав. Вместо этого, программы, работающие от имени непользователя, могут использовать определенные локации в рамках своей домашней директории.
Рекомендованные директории для хранения данных
-
$XDG_DATA_HOME
($HOME/.local/share
):- Эта директория рекомендуется для хранения данных, которые могут быть использованы приложениями и которые не стоят на первом месте по значимости, но при этом могут изменяться в процессе работы. Например, базы данных и кэшированные файлы.
- Применение: карты, закладки, и прочие данные, изменяющиеся во время работы программы.
-
$XDG_CACHE_HOME
($HOME/.cache
):- Это место для временных файлов и кэша, которые могут быть созданы различными приложениями. Важно отметить, что данные здесь могут быть более «объемными» и менее важными, чем те, что находятся в
$XDG_DATA_HOME
. - Применение: кешированные изображения, данные для быстрого доступа, временные файлы и логи, которые могут быть позже очищены.
- Это место для временных файлов и кэша, которые могут быть созданы различными приложениями. Важно отметить, что данные здесь могут быть более «объемными» и менее важными, чем те, что находятся в
-
$XDG_STATE_HOME
($HOME/.local/state
):- Эта директория предназначена для хранения состояния пользователя между запусками приложения. Это может включать в себя журналы действий или текущее состояние пользователей.
- Применение: история действий, текущее состояние приложения, временные файлы, которые не критичны для перезапуска.
-
Локальные каталоги для временных данных:
- Файлы, которым нет необходимости сохранять между сессиями и которые могут быть удалены, могут храниться прямо в
$TMPDIR
или в других временных директориях, таких как/tmp
, которые, как правило, доступны всем пользователям. Никаких отдельных решений для хранение таких данных в домашней директории не требуется.
- Файлы, которым нет необходимости сохранять между сессиями и которые могут быть удалены, могут храниться прямо в
Выводы
В контексте вышеизложенного, рекомендуется применять следующие конвенции:
- Для логов: использовать
$XDG_STATE_HOME
. - Для временных и кэшированных файлов: использовать
$XDG_CACHE_HOME
. - Для данных, которые необходимо сохранить между сессиями, но которые не являются критически важными для работы программы: используется
$XDG_DATA_HOME
.
Эти подходы позволят организовать рабочее пространство для приложений в личной директории пользователя, сохраняя при этом порядок, минимизируя «загромождение» и поддерживая высокую степень управления данными. Это не только соответствует современным стандартам, но и позволяет создавать более чистые и удобные для пользователя приложения.