Существует ли путь POSIX, который не может назвать файл?
Есть ли какие-либо легальные пути в POSIX, который не может быть связан с файлом, регулярным или неправильным? Таким образом, для который test -e "$LEGITIMATEPOSIXPATHNAME" не может успешно выполниться?
Разъяснение № 1: пути
"Легальными путями в POSIX", я имею в виду, которые, как POSIX говорит, позволяются, не, которые явно не запрещает POSIX. Я искал, это, и является спецификацией POSIX, называет их символьными строками что:
- Использование только символы от переносимого набора символов для имен файлов
[a-zA-Z0-9._-](cf. http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276); - Не начинать
-; и - Имейте длину между 1 и NAME_MAX, число, неуказанное для POSIX, который является не меньше чем 14.
POSIX также признает, что файловые системы будут, вероятно, более ослаблены, чем это, но он запрещает символы NUL и / от появления в именах файлов. Обратите внимание что такой парадигматически имя файла UNIX как lost+found не FPF, согласно этому определению. Существует другой постоянный PATH_MAX, для использования которого не нужно никакое дальнейшее объяснение.
Идеальный ответ будет использовать FPFs, но я интересуюсь любым примером с именами файлов, которые явно не запрещает POSIX.
Разъяснение № 2: невозможность
Очевидно, пути обычно могли связываться с файлом. Но семантика UNIX скажет Вам, что существуют специальные места, которым нельзя было обычно создавать произвольные файлы, как в /dev каталог. Какие-либо такие специальные места предусмотрены в POSIX? Именно это вопрос получает после.
4 ответа
Так как заключительный вопрос состоит в том, существуют ли специальные места, которые не могли бы обычно иметь файла, как в/dev каталоге, предусмотренном в POSIX, затем andswer - ДА.
Полный список предопределенных файлов и каталоги даны в главе 10, Структуре каталогов POSIX и Устройствах, Выпуска 6 Спецификаций Основы IEEE Open Group:
Следующие каталоги должны существовать в соответствующих системах, и соответствующие приложения должны использовать их только, как описано. Строго соответствующие приложения не должны принимать способность создать файлы в любом из этих каталогов, если не указано ниже.
/
Корневой каталог.
/dev
Содержит/dev/console,/dev/null, и/dev/tty, описанный ниже.Следующий каталог должен существовать в соответствующих системах и должен использоваться, как описано:
/tmp
Каталог сделал доступным для приложений, для которых нужно место для создания временных файлов. Приложениям нужно позволить создать файлы в этом каталоге, но не должны предполагать, что такие файлы сохраняются между вызовами приложения.Следующие файлы должны существовать в соответствующих системах и должны быть и читаемы и перезаписываемы:
/dev/null
Бесконечный источник данных и приемник данных. Данные, записанные в/dev/null, должны быть отброшены. Чтения от/dev/null должны всегда возвращать конец файла (EOF).
/dev/tty
В каждом процессе, синониме для терминала управления, связанного с группой процесса того процесса, если таковые имеются. Это полезно для программ или процедур оболочки, которые хотят быть уверенными в записи сообщений к или чтении данных с терминала, неважно, как произведенный был перенаправлен. Это может также использоваться для приложений, которые требуют, чтобы название файла для вывода, когда введено произведенного, было желаемо, и это утомительно для обнаружения, какой терминал используется в настоящее время.Следующий файл должен существовать в соответствующих системах и не должен быть читаем или перезаписываем:
/dev/console
/dev/console файл является родовым названием, данным системной консоли (см. Системную Консоль). Это обычно связывается с определенным реализацией специальным файлом. Это должно предоставить интерфейс системной консоли, соответствующей требованиям Основного объема Определений Станд. IEEE 1003.1-2001, Главы 11, Общего Терминального интерфейса.
"Легальный путь в POSIX" уже означает, что может указать на объект файловой системы (файл, каталог, символьная ссылка, и т.д.).
На долгом размышлении некоторые файловые системы (такие как FAT) имеют ограничения на допустимые символы в именах файлов. Таким образом в моем компьютере, ~/fs/phone/This:is*a?file|name.txt был бы отклонен vfat драйвер файловой системы.
Отвечать на второй вопрос, test -e "$LEGITIMATEPOSIXPATHNAME" сбои, когда файл не существует, очевидно.
Тестирование на имя файла с нулевым символом в нем должно всегда перестать работать.
POSIX резервирует '/' и пустой указатель от имен файлов. Это разумно: каждый - разделитель каталога, и каждый - строковый разделитель. Для поддержки той точки Википедия говорит, что ext2, ext3, и ext4 позволяют все байты в именах файлов кроме пустого указателя и наклонной черты вправо. NTFS, действительно ли в режиме эмуляции POSIX, запрещает немного больше, чем это; и варианты FAT также запрещают пустой указатель. В теории это действительно зависит от файловой системы. Но я не задержал бы свое дыхание, пытающееся найти случай, где пустой указатель находит свой путь в имя файла.
Тест перестал бы работать, если имя файла повреждает ограничения локального внедрения POSIX.
Каждая существующая файловая система делает предположения как относительно максимальных длин, пределов рекурсии каталога и т.д. Таким образом, имя POSIX, это законно в одной операционной системе, не могло бы быть официальным на другом.
Таким образом, мой ответ на вопрос - "Да":
Даже имена, которые являются официальными при тестировании в одной системе POSIX могут быть отклонены другим из-за ограничений реализации.