Что касается жесткой ссылки - PullRequest
9 голосов
/ 29 апреля 2011

Может кто-нибудь объяснить, почему ядро ​​не позволяет нам сделать жесткую ссылку на каталог. Является ли это тем, что нарушает правило структуры ориентированного ациклического графа файловой системы, или по какой-то другой причине. Какие еще осложнения возникают, если это позволяет?

Ответы [ 5 ]

17 голосов
/ 09 мая 2011

Во времена 7-й редакции (или версии 7) UNIX не было системных вызовов mkdir(2) и rmdir(2). Программа mkdir(1) была корневым SUID и использовала системный вызов mknod(2) для создания каталога и системный вызов link(2) для создания записей для . и .. в новом каталоге. Системный вызов link(2) позволял делать это только root. Следовательно, еще тогда (около 1978 г.) суперпользователь мог создавать ссылки на каталоги, но только суперпользователю было разрешено делать это, чтобы гарантировать отсутствие проблем с циклами или другими недостающими ссылками. Существовали диагностические программы, которые собирали фрагменты, если система зависала, когда каталог был частично создан, например.


Руководства по Unix 7th Edition можно найти по адресу Bell Labs . Разделы 2 и 3 лишены mkdir(2) и rmdir(2). Вы использовали системный вызов mknod(2) для создания каталога:

ИМЯ

mknod - сделать каталог или специальный файл

1024 * СИНТАКСИС * mknod(name, mode, addr) char *name; ОПИСАНИЕ

Mknod создает новый файл, именем которого является строка с нулевым символом в конце, указанная именем. Режим работы новый файл (включая каталог и специальные биты файла) инициализируется из режима. (Защитная часть режим изменяется маской режима процесса; см. umask (2)). Указатель первого блока i-узла инициализируется из addr. Для обычных файлов и каталогов addr обычно равен нулю. В случае специального file, addr указывает, какой специальный файл.

Mknod может вызываться только суперпользователем.

СМОТРИТЕ ТАКЖЕ

mkdir (1), mknod (1), filsys (5)

ДИАГНОСТИКА

Ноль возвращается, если файл был создан; - 1, если файл уже существует или пользователь не является суперпользователем.

Запись для link(2) гласит:

ДИАГНОСТИКА

Ноль возвращается при создании ссылки; - 1 возвращается, когда name1 не может быть найдено; когда name2 уже существует; когда каталог name2 не может быть записан; когда попытка сделать ссылку на каталог пользователь, отличный от суперпользователя; когда сделана попытка связать файл с другой файловой системой; когда В файле слишком много ссылок.

Запись для unlink(2) состояния:

ДИАГНОСТИКА

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

Страница руководства для команды ln(1):

Запрещено ссылаться на каталог или ссылаться на файловые системы.

Страница руководства для примечаний к команде mkdir(1):

Стандартные записи, '.', Для самого каталога и '..' для его родителя, сделаны автоматически.

Это не заслуживает комментариев, если бы не было возможности создавать каталоги без этих ссылок.


В настоящее время системные вызовы mkdir(2) и rmdir(2) являются стандартными и позволяют любому пользователю создавать и удалять каталоги, сохраняя правильную семантику. Больше нет необходимости разрешать пользователям создавать жесткие ссылки на каталоги. Это вдвойне верно, поскольку были введены символические ссылки - их не было в 7-м издании UNIX, но они были в BSD-версиях UNIX с самого начала.


СВ обычных каталогах запись .. однозначно ссылается на родительский каталог (одиночный, одиночный) . Если у вас есть две жесткие ссылки (два имени) для одного и того же каталога в разных каталогах, где находится точка входа ..? Предположительно, в исходный родительский каталог - и, по-видимому, нет способа попасть в «другой» родительский каталог из связанного каталога. Это асимметрия, которая может вызвать проблемы. Обычно, если вы делаете:

chdir("./subdir");
chdir("..");

(где ./subdir не является символической ссылкой), тогда вы вернетесь в каталог, из которого начали. Если ./subdir - это жесткая ссылка на каталог где-то еще, то вы будете в другом каталоге, с которого вы начали после второго chdir(). Вы должны показать это с помощью пары stat() вызовов до и после показанных операций chdir().

6 голосов
/ 29 апреля 2011

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

4 голосов
/ 29 апреля 2011

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

В UNIX,во многих программах используется общее предположение, согласно которому все каталоги будут иметь число ссылок 2 + количество дочерних каталогов.Это связано со стандартными записями каталога POSIX '.'и «..», которая ссылается на каталог или его родителя.

( После проверки могу сказать, что root (/) не является исключением ).

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

Уточнение Если разрешить жесткие ссылки на каталоги, определенные пользователем, эти, так сказать, 1011 больше не будут хранитьсяи любые зависимые приложения могут перестать работать правильно.Элемент неожиданности заключается в том, почему вам нужны права суперпользователя (и некоторое хорошее проектное (пере) мышление), чтобы форсировать создание жестких ссылок каталога

3 голосов
/ 04 мая 2011

Циклические ссылки прерывают сборку мусора путем подсчета ссылок. Википедия описывает проблему:

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

То, как это делает Linux.

3 голосов
/ 29 апреля 2011

Потому что тогда дерево каталогов перестанет быть деревом каталогов.В одном каталоге может быть несколько родителей.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...