Кусалананда уже сказал вам, что это поведение определяется стандартом POSIX. Тем не менее, история UNIX всерьез началась в начале 1970-х годов. POSIX появился лишь во второй половине 1980-х годов, то есть на целых полтора десятилетия позже. На практике POSIX просто указывал, что уже делается реализациями.

Скорее, UNIX очень рано поддерживала монтирование файловых систем на разных устройствах в единую унифицированную иерархию каталогов. Фактически каждая файловая система имеет собственный корневой каталог; файловая система, смонтированная по адресу /, ничем особенным не отличается. (Его содержимое может быть, но сама файловая система — нет.)

Системные вызовы sysmountи sysumount, по-видимому, были введены в UNIX V1, в 1970 -1971 (V1 датирована 1971 -11, согласно дереву Unix в The Общество наследия Unix). Они определены в u1.s(номера системных вызовов 21 и 22 соответственно )и реализованы в u7.s . (PDP7 UNIX, датированный 1970 -01, , похоже, не имеет явного предка).

Вы, вероятно, понимаете, к чему это приводит, :когда любая файловая система может быть смонтирована в любом месте в иерархии, чтобы избежать необходимости в особых -случаях., каждый каталог, включая корневой каталог каждой файловой системы, должен содержать запись, указывающую на его собственный родительский каталог. На диске логичным местом для указания записи родительского каталога корневого каталога файловой системы является корневой каталог файловой системы, потому что нет ничего «выше» корневого каталога файловой системы.Концепция наличия чего-то «выше» корневого каталога вступает в игру только тогда, когда эта файловая система смонтирована в каком-либо месте, отличном от корня иерархии.

Во время монтирования можно переписать указатель «родительский каталог» в копии памяти корневого каталога, чтобы он указывал на родительский каталог каталога точки монтирования. Если нет родительского каталога каталога точки монтирования (, другими словами, файловая система монтируется как /), тогда просто оставьте этот фрагмент данных в покое (, потому что, скорее всего, больше некуда его указать. в любом случае )или обработайте его отдельно позже (, как, вероятно, в случае /../hostname/pathи //hostname/path, упомянутых в ответе Кусалананды ).

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

Там находится каталог выше /, /. Родительским каталогом корневого каталога является он сам. cd..или cd../..внутри корневого каталога должны оставить вас на том же месте, а не вызвать ошибку.

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

Предполагается, что путь, подобный /../hostname, позволяет вам получить доступ к корню другого хоста в некоторых ранних системах до -vfs и до -nfs, таких как MUNIX (, используя " Newcastle Connection» ), но я не знаю ни одной такой системы, которая все еще используется, и исходный код нигде не найден.

Доступная информация весьма противоречива, но кажется, что наиболее распространенным способом развертывания такой системы была перекомпиляция всех программ, чтобы можно было перенаправить все пути -с использованием вызовов типа open(2). в пользовательском пространстве (в то время не было общих библиотек ).

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

Помимо всех других причин, упомянутых здесь, это простота конструкции , то, чем славится UNIX. Все каталоги содержат ..; особые случаи — это всегда опасность споткнуться (из-за безопасности или надежности ), вырисовывающаяся в темноте. Таким образом, вместо того, чтобы заставлять программистов иметь дело с одним редким случаем во многих местах, все каталоги спроектированы так, чтобы иметь записи .и ..и обрабатываются единообразно, и рассмотрение того, что происходит в /, не требуется.