Каталоги XDG Basedir для Windows

Я создал библиотеку Racket library для удобства доступа к каталогам XDG Basedir. Поскольку я хочу, чтобы библиотека также использовалась в Windows (для кроссплатформенных программ), я использую стандартные каталоги Windows в качестве значений по умолчанию, когда переменные среды XDG не установлены.

В настоящее время я использую следующее:

$XDG_DATA_HOME = %LOCALAPPDATA%
$XDG_DATA_DIRS = %APPDATA%
$XDG_CONFIG_HOME = %LOCALAPPDATA%
$XDG_CONFIG_DIRS = %APPDATA%
$XDG_CACHE_HOME = %TEMP%
$XDG_RUNTIME_DIR = %TEMP%

У меня вопрос, есть ли лучшие значения по умолчанию, чем те. Я знаю, что %TEMP% как $XDG_RUNTIME_DIR не так, так как он действительно должен быть на ramfs, как /tmp, но я не знаю ни одного каталога в Windows, подобного этому. В Windows кажется, что нет хорошего способа разделить каталоги данных и конфигурации, поэтому я использую для них одни и те же каталоги. У меня есть ощущение, что %LOCALAPPDATA% - лучший выбор для доступных для записи переменных $XDG_*_HOME и иметь конфигурацию "роуминга" в списках $XDG_*_DIRS для чтения и, как правило, не перезаписывать. Но сочтут ли странные и несогласные корпоративные пользователи Windows, имеющие конфигурацию роуминга, странным и несогласным?

Ответ 1

Я реализовал такую функциональность в библиотеках для JVM и Rust. Вот что я узнал:

Разберитесь с именами приложений, потому что ваши пользователи не могут или не хотят.

Предоставьте API, которые вычисляют полный путь (включая имя приложения!) К каталогам конфигурации, кэша и т.д. Невыполнение этого требования приведет к тому, что код будет гарантированно ошибочным как минимум на 2 из 3 основных платформ, поскольку соглашения существенно отличаются.

Рассмотрим приложение, написанное компанией MegaCorp (веб-адрес MegaCorp.co.uk) под названием Foo App. В Linux сегмент пути с именем приложения должен быть fooapp/ (в нижнем регистре, без пробелов), в Windows это должно быть MegaCrop\Foo App\ (обратите внимание на две папки), а в macOS это должно быть uk.co.MegaCorp.Foo-App (недопустимые символы заменено на -).

Четкое определение цели для каждого каталога.

Например, моя библиотека не предлагает runtimeDir в macOS или Windows, потому что XDG_RUNTIME_DIR сильно отличается от e. грамм. %TEMP% в Windows.

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

Также я предлагаю fontDir только для Linux и macOS. В Windows есть каталог шрифтов, но в отличие от Linux и macOS он недоступен для записи пользователем.

С другой стороны, я предлагаю dataDir (%APPDATA%) и dataLocalDir (%LOCALAPPDATA%) на всех трех платформах. В macOS и Linux эти каталоги возвращают один и тот же путь - это явное проектное решение, учитывающее, как пользователи будут писать код, если один из этих каталогов будет недоступен: пользователи либо забудут его обработать, либо просто откроют другой каталог. С выбранным дизайном это работает "из коробки", и пользователям не нужно думать об этом.

Избегайте проблем до того, как пользователь столкнется с ними.

Вот почему общие пути к кешу, каталогам конфигурации и т.д. возвращают %LOCALAPPDATA% и %APPDATA%, а специфичные для приложения пути к каталогам и каталогам конфигурации возвращают %LOCALAPPDATA%\Company\Application\cache и %APPDATA%\Company\Application\config.

Обратите внимание на подкаталоги! Это должно гарантировать чистое разделение кэша приложения, конфигурации и каталога данных независимо от того, какие странные настройки Windows могут быть у пользователя.

Разбейте варианты использования на отдельные модули.

В моей библиотеке есть три отдельных модуля с четко определенными отдельными случаями использования:

BaseDirs, который запрашивает пути невидимых пользователем стандартных каталогов (кеш, конфиг, данные, исполняемые файлы, каталоги времени выполнения) и настоятельно рекомендует вместо этого использовать ProjectDirs.

ProjectDirs, который вычисляет расположение каталогов кэша, конфигурации или данных для вашего собственного приложения или проекта, которые получены из стандартных каталогов.

UserDirs, который запрашивает пути стандартных пользовательских каталогов (Аудио, Документы, Загрузки и т.д.).

В то время как BaseDirs и UserDirs имеют довольно неинтересные конструкторы (new()), ProjectDirs предоставляет этот метод фабрики:

ProjectDirs::from(qualifier: &str, organization: &str, application: &str)

Этот метод гарантирует, что пользователи в конечном итоге получат правильные, совместимые со стандартами пути к каталогам кеша, конфигурации и т.д. Своих приложений, при этом им не нужно будет знать обо всех тонкостях каждой отдельной платформы.

Последнее предложение: я бы держал библиотеку с именем "Библиотека XDG Basedir", ориентированную на Linux, и публиковал бы библиотеку с более общим именем, например "Стандартная библиотека каталогов", которая работает с Linux, Windows и т.д., Чтобы избежать путаницы.

Надеюсь, это было полезно!