Почему жесткие ссылки не разрешены для каталогов?


129

Я использую Ubuntu 12.04. Когда я пытаюсь создать жесткую ссылку для любой директории, она не работает. Я могу создать жесткие ссылки для файлов внутри границы файловой системы. Я знаю причину, по которой мы не можем создавать жесткие ссылки для файлов за пределами файловой системы.

Я попробовал эти команды:

$ ln /Some/Direcoty /home/nischay/Hard-Directory
hard link not allowed for directory
$ sudo ln /Some/Direcoty /home/nischay/Hard-Directory
[sudo] password for nischay: 
hard link not allowed for directory

Я просто хочу знать причину этого. Это одинаково для всех дистрибутивов GNU / Linux и Unix-версий (BSD, Solaris, HP-UX, IBM AIX) или только в Ubuntu или Linux?



2
Попробуйте ln -F <src> <dst>и это может сработать. Конечно, раньше он работал на суперпользователя в старых версиях Unix. Кто-нибудь помнит, был ли это UCB или System V? Да, плохие вещи могут случиться, но обычно нет. Насколько я помню, rmdirзнал , что не следует удалять прошлые жесткие ссылки. Тем не менее, пользователи могут запутаться и удалить вещи по ошибке.
Стив Питчерс

@StevePitchers Как rmdirобрабатывать жесткие ссылки особым образом? Жесткая ссылка - это обычная ссылка, но дополнительная. Даже нелегко узнать, существуют ли необычные дополнительные ссылки без дополнительных записей.
Фолькер Сигел

1
Каждый узел хранит количество жестких ссылок, которые указывают на него: содержимое освобождается только тогда, когда нет оставшихся ссылок. Так что rmdirможете сказать, есть ли в каталоге ссылки из других мест. Рекурсивное удаление rm -rдолжно быть закодировано с осторожностью, чтобы быть уверенным, что оно будет работать правильно даже в случае ошибок типа «отказано в разрешении». Кстати, UCB = BSD, дох!
Стив Питчерс

2
Я сделал ln -Fна каталогах, и это работает. Но вы не рискуете впоследствии удалить каталог, опасаясь испортить файловую систему.
Эдвард Фальк

Ответы:


159

Жесткие ссылки на каталоги нарушают файловую систему несколькими способами

Они позволяют создавать петли

Жесткая ссылка на каталог может ссылаться на самого родителя, который создает цикл файловой системы. Например, эти команды могут создать цикл с обратной ссылкой l:

mkdir -p /tmp/a/b
cd /tmp/a/b
ln -d /tmp/a l

Файловая система с циклом каталогов имеет бесконечную глубину:

cd /tmp/a/b/l/b/l/b/l/b/l/b

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

Файловая система с такой жесткой ссылкой больше не является деревом, потому что дерево по определению не должно содержать цикл.

Они нарушают однозначность родительских каталогов

В цикле файловой системы существует несколько родительских каталогов:

cd /tmp/a/b
cd /tmp/a/b/l/b

В первом случае /tmp/aэто родительский каталог /tmp/a/b.
Во втором случае /tmp/a/b/lэто родительский каталог /tmp/a/b/l/b, который совпадает с /tmp/a/b.
Таким образом, у него есть два родительских каталога.

Они умножают файлы

Файлы идентифицируются путями после разрешения символических ссылок. Так

/tmp/a/b/foo.txt
/tmp/a/b/l/b/foo.txt

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

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

Ваш пример

$ ln /Some/Direcoty /home/nischay/Hard-Directory
$ echo foo > /home/nischay/Hard-Directory/foobar.txt
$ diff -s /Some/Direcoty/foobar.txt /home/nischay/Hard-Directory/foobar.txt
$ echo bar >> /Some/Direcoty/foobar.txt
$ diff -s /Some/Direcoty/foobar.txt /home/nischay/Hard-Directory/foobar.txt
$ cat /Some/Direcoty/foobar.txt
foo
bar

Как тогда могут работать мягкие ссылки на каталоги?

Путь, который может содержать программные ссылки и даже программно-связанные циклы каталогов, часто используется только для идентификации и открытия файла. Его можно использовать как обычный линейный путь.

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

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

Команда readlinkможет разрешить путь к своему каноническому пути:

$ readlink -f /some/symlinked/path

Мягкие ссылки отличаются от того, что использует файловая система

Мягкая ссылка не может вызвать все проблемы, потому что она отличается от ссылок внутри файловой системы. Его можно отличить от жестких ссылок и при необходимости разрешить по пути без символических ссылок.
В некотором смысле добавление символических ссылок не меняет основную структуру файловой системы - она ​​сохраняет ее, но добавляет дополнительную структуру, например уровень приложения.


От man readlink:

 NAME
        readlink - print resolved symbolic links or canonical
        file names

 SYNOPSIS
        readlink [OPTION]... FILE...

 DESCRIPTION
        Print value of a symbolic link or canonical file name

        -f, --canonicalize
               canonicalize by  following  every  symlink  in
               every component of the given name recursively;
               all but the last component must exist
        [  ...  ]

1
Почему мягкая ссылка не может сделать все это?
Танай

1
@Tanay Правильно, это может помочь расширению сравнить его с аналогичными случаями с мягкими ссылками. Я попытаюсь.
Фолькер Сигел

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

отличный ответ, но тогда ... как Apple решила эти проблемы для Time Machine?
Дэмиен

Звучит очень интересно! Но я ничего не знаю о том, в чем проблема - вы можете дать мне подсказку?
Фолькер Сигел

77

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

Симлинки могут:

  • Указать на каталоги
  • Указывать на несуществующие объекты
  • Укажите файлы и каталоги вне одной и той же файловой системы

Жесткие ссылки могут:

  • Сохранить файл, на который они ссылаются, от удаления

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

Команда cp -alособенно полезна в этом отношении. Он создает полную копию структуры каталогов, где все файлы представлены жесткими ссылками на исходные файлы. Затем вы можете приступить к обновлению файлов в структуре, и только файлы, которые вы обновите, займут дополнительное пространство. Это особенно полезно при сохранении резервных копий нескольких поколений.


41
Что касается последнего абзаца, если вы редактируете «скопированный» файл с жесткими ссылками
marcin

32
Это описание жестких ссылок довольно обманчиво. По сути, это правда, что жесткие ссылки «удерживают файл, на который они ссылаются, от удаления», но это всего лишь побочный эффект жестких ссылок. Это, конечно, НЕ верно, что вы можете создать жесткие ссылки в одном каталоге, изменить «оригинальный» файл, а затем ожидать, что жесткие ссылки каким-то образом укажут на старый контент. Фактически, главная истина жестких ссылок заключается в том, что это вовсе не ссылка, по крайней мере, не более, чем оригинальный «файл», который является просто именем, указывающим на файл. Жесткая ссылка - это просто другое имя, указывающее на тот же файл.
Мэтти

7
Идея резервного копирования хороша, и я действительно часто ее использую, но я думаю, что пользователей следует предупредить, что изменение файла также изменит резервную копию.
Марк

3
Черт, символическая ссылка не должна указывать на что-либо вообще. ln -s "Don't use this directory" READMEзаконно Фактически, если вы подумаете об этом, каталог может использоваться как реляционная база данных и вообще не содержать никаких реальных файлов.
Эдвард Фальк

5
-1 Это не отвечает на вопрос, и некоторая информация совершенно неверна.
wjandrea

43

К вашему сведению, вы можете добиться того же, что и жесткие ссылки для каталогов, используя mount:

mount -t bind /var/www /home/user/workspace/www

Это очень опасно, потому что большинство инструментов и программ не будут знать о привязке . Однажды я сделал что-то подобное в приведенном выше примере, а затем приступил к rm -rf /home/user. К счастью, не было ничего уместного в /var/www.


6
Я использовал mount --bind <src> <dest>. Используйте с осторожностью, чтобы не вытереть src;)
kachar

1
Я получаю:mount: unknown filesystem type 'bind'
Визек

4
на Busybox, это оноmount -o bind src dest
Mat M

@MatM то же самое с Debian
hanshenrik

2
Если вам нужно только смонтировать для чтения, вы можете установить разрешения для точки монтирования и избежать rm -rfпроблемы. superuser.com/questions/320415/…
zanerock

19

Причина, по которой жесткие ссылки на каталоги не разрешены, является немного технической. По сути, они нарушают структуру файловой системы . Как правило, вы не должны использовать жесткие ссылки в любом случае. Символьные ссылки обеспечивают большую часть той же функциональности, не вызывая проблем (например ln -s target link).


17
Жесткие ссылки имеют хорошие варианты использования. Сказать, что вы вообще не должны их использовать, слишком много.
Сандер Штеффанн

4
+2 за предоставление ссылки, которая фактически отвечает на вопрос ОП (и мой), -1 за высказывание мнения («В общем, вам не следует использовать жесткие ссылки» - если бы у него были ссылки для его поддержки, это было бы нормально). Это было хорошо, потому что я не могу дать +2 в любом случае. ; D
MSB

3
ссылка "они нарушают структуру файловой системы" не работает.
Чарли Паркер

5
Попробуйте обобщить содержание ссылки в ответе и сохранить ссылку в качестве ссылки. Это хорошая практика, чтобы избежать гниения ссылок, спасибо.
Oxwivi

3
молодец @CharlieParker; лучший непреднамеренный (?) ироничный комментарий всех времен :)
Элиран Малка
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.