Подтвердить что ты не робот

Где хранить данные приложения (не относящиеся к пользователю) в Linux

В моем Java-приложении на основе OSGi я разрабатываю пакет, чтобы предоставить остальной системе доступ к файловой системе. Помимо предоставления доступа к домашнему каталогу пользователя, я также хочу предоставить доступ к области, не связанной с пользователем. Точно, что эта область будет использоваться для пока еще не определена, но она не будет для предпочтений (обрабатывается другим пакетом), однако она может использоваться для хранения данных, которые могут меняться во время выполнения.

Я намерен использовать следующие каталоги для этой цели:

  • Windows Vista и Windows 7: "\ ProgramData".
  • Windows XP: "\ Documents and Settings\All Users".
  • Mac OS X: "/Library/Поддержка приложений".

Где разумный эквивалент в Linux и как мне получить дескриптор этого кода Java?

4b9b3361

Ответ 1

Это зависит от того, какие данные вы планируете хранить. Этот ответ заключается в том, что вы сохраняете и изменяете данные во время выполнения.

Вопреки тому, что предложили другие, я бы рекомендовал не использовать /usr/share для хранения. Из стандарта иерархии файловой системы:

Иерархия /usr/share предназначена для всех файлов данных, независимых от архитектуры только для чтения.

Когда вы изменяете данные, это противоречит /usr подсистемы /usr чтения.

По-видимому, лучшим местом для хранения данных состояния приложения будет /var или, более конкретно, /var/lib. Это также исходит из Стандарта иерархии. Вы можете создать /var/lib/myapp, или если вы также используете такие вещи, как блокировки файлов или журналов, вы можете использовать /var/lock или /var/log.

Углубленный взгляд на стандарт в целом (связанный с выше) - вы можете найти место, которое соответствует тому, что вы хотите сделать еще лучше.

Как и Стив К, я бы также рекомендовал использовать API настроек для данных предпочтений приложения.

Ответ 2

Это зависит.

  • Глобальная конфигурация → /etc/appname

  • Только для чтения, независимо от архитектуры машины → /usr/share/appname

  • Только для чтения, специфичный для машины → /usr/lib/appname

  • Чтение-запись → /var/lib/appname

Нет гарантии на полноту, пожалуйста, проверьте Стандарт иерархии файловой системы.

Ответ 3

Поскольку вы используете Java, просмотрели ли вы API настроек?

Из введения:

Приложения требуют предпочтения и данные конфигурации для адаптации к потребностям разных пользователей и сред. Пакет java.util.prefs предоставляет возможность приложениям хранить и извлекать данные о предпочтениях пользователей и систем и настройках. Данные хранятся постоянно в хранилище поддержки, зависящем от реализации. Существует два отдельных дерева предпочтительных узлов: один для пользовательских настроек и один для системных настроек

Я бы включил встроенный API.

Ответ 4

Проект freedesktop.org (ранее известный как X Desktop Group) определил некоторые стандарты для этого в Спецификация базового каталога XDG.

В вашем случае я бы посмотрел на $XDG_DATA_DIRS:

$XDG_DATA_DIRS определяет упорядоченный по предпочтению набор базовых каталогов для поиска файлов данных в дополнение к базовому каталогу $XDG_DATA_HOME. Каталоги в $XDG_DATA_DIRS должны быть разделены двоеточием ':'.

Если $XDG_DATA_DIRS либо не задано, либо пустое, должно использоваться значение, равное /usr/local/share/:/usr/share/.

Я настоятельно рекомендую прочитать Спецификацию базового каталога XDG.

Ответ 5

В папках /usr/share или/usr/local/share

Ответ 6

Если он не является специфичным для пользователя, вы, вероятно, можете его сохранить в каталоге/usr/share/appname

Ответ 7

Я знаю, что это старый вопрос, но согласно https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard (который, кажется, обновляется и корректируется с июля 2015 года)...

Предполагая, что файлы данных, как понимается, не соответствуют требованиям /tmp или /var/tmp, затем /usr/local/share/theApp или /usr/local/theApp.

Ответ 8

Вы хотите сделать это так жестко. Вы можете использовать System.getProperty( "user.home" ), чтобы получить пользователей домой, чтобы он стал более независимым от платформы.