4

Существуют ли в POSIX допустимые пути, которые нельзя связать с файлом, обычный или неправильный? То есть, для какого test -e "$LEGITIMATEPOSIXPATHNAME" не может пройти успешно?

Разъяснение № 1: пути

Под "легальными путями в POSIX" я подразумеваю те, которые, как говорит POSIX, разрешены, а не те, которые POSIX явно не запрещает. Я посмотрел это, и спецификация POSIX называет их символьными строками, которые:

  1. Используйте только символы из переносимого набора символов имени файла [a-zA-Z0-9._-] (см. Http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276);
  2. Не начинайте с - ; а также
  3. Длина от 1 до NAME_MAX, число, не указанное для POSIX, не менее 14.

POSIX также допускает, что файловые системы, вероятно, будут более расслабленными, чем эта, но запрещает символы NUL и / появляться в именах файлов. Обратите внимание, что такое парадигматически имя файла UNIX, как lost+found , не является FPF, согласно этому определению. Есть еще одна константа PATH_MAX, использование которой не нуждается в дополнительном объяснении.

Идеальный ответ будет использовать FPF, но меня интересует любой пример с именами файлов, которые POSIX явно не запрещает.

Разъяснение № 2: невозможность

Очевидно, что имена путей обычно могут быть связаны с файлом. Но семантика UNIX скажет вам, что есть специальные места, в которых обычно не могут быть созданы произвольные файлы, как в каталоге /dev . Есть ли в POSIX такие специальные места? Вот к чему идет вопрос.

|источник

5 ответов5

3

Поскольку последний вопрос заключается в том, существуют ли специальные места, в которых обычно не может быть файла, например, в каталоге /dev, указанном в POSIX, тогда ответом будет YES.

Полный список предварительно определенных файлов и каталогов приведен в главе 10 « Структура и устройства каталогов POSIX » Базовых спецификаций IEEE Open Group Base Issue 6:

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

/
Корневой каталог.
/ DEV
Содержит / dev / console, / dev / null и / dev / tty, как описано ниже.

Следующий каталог должен существовать в соответствующих системах и должен использоваться как описано:

/ TMP
Каталог, доступный для приложений, которым требуется место для создания временных файлов. Приложениям разрешается создавать файлы в этом каталоге, но не следует предполагать, что такие файлы сохраняются между вызовами приложения.

Следующие файлы должны существовать в соответствующих системах и должны быть доступны для чтения и записи:

/ DEV / нуль
Бесконечный источник данных и приемник данных. Данные, записанные в / dev / null, должны быть отброшены. Чтение из / dev / null всегда должно возвращать конец файла (EOF).
/ DEV / TTY
В каждом процессе - синоним управляющего терминала, связанного с группой процессов этого процесса, если таковой имеется. Это полезно для программ или процедур оболочки, которые хотят быть уверены в записи сообщений или чтении данных с терминала, независимо от того, как перенаправлен вывод. Он также может использоваться для приложений, которые требуют имя файла для вывода, когда требуется типизированный вывод, и утомительно выяснять, какой терминал используется в настоящее время.

Следующий файл должен существовать в соответствующих системах и не должен быть доступен для чтения или записи:

/ DEV / консоли
Файл / dev / console - это общее имя, данное системной консоли (см. Системная консоль). Обычно он связан с определенным реализацией специальным файлом. Он должен обеспечивать интерфейс к системной консоли, соответствующий требованиям тома Базовых определений стандарта IEEE Std 1003.1-2001, Глава 11, Общий интерфейс терминала.

|источник
3

Тестирование имени файла с нулевым символом в нем всегда должно завершаться неудачей.

POSIX резервирует '/' и ноль из имен файлов. Это разумно: один является разделителем каталогов, а другой - разделителем строк. Чтобы поддержать эту точку, Википедия говорит, что ext2, ext3 и ext4 разрешают все байты в именах файлов, кроме null и косой черты. NTFS, в режиме POSIX-совместимости или нет, запрещает немного больше; и варианты FAT также запрещают ноль. Теоретически, это действительно зависит от файловой системы. Но я не задерживаю дыхание, пытаясь найти случай, когда null находит путь к имени файла.

|источник
2

/dev/null/impossible не может существовать. Это потому, что /dev/null должен быть файлом, и поэтому не может быть каталогом.

То же самое для /dev/tty/impossible и /dev/console/impossible

|источник
1

"Правильный путь в POSIX" уже означает, что он может указывать на объект файловой системы (файл, каталог, символическая ссылка и т.д.).

Во-вторых, некоторые файловые системы (например, FAT) имеют ограничения на допустимые символы в именах файлов. Итак, на моем компьютере ~/fs/phone/This:is*a?file|name.txt будет отклонен драйвером файловой системы vfat .

Чтобы ответить на второй вопрос, test -e "$LEGITIMATEPOSIXPATHNAME" завершается неудачно, когда файл, очевидно, не существует.

|источник
0

Тест не пройдёт, если имя файла нарушит ограничения локальной реализации POSIX.

Каждая существующая файловая система делает предположения относительно максимальной длины, пределов рекурсии каталогов и многого другого. Поэтому имя POSIX, допустимое в одной операционной системе, может быть недопустимым в другой.

Поэтому мой ответ на вопрос "да":
Даже имена, которые являются законными при тестировании в одной системе POSIX, могут быть отклонены другой из-за ограничений реализации.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .