В чем разница между символической ссылкой и жесткой ссылкой? - PullRequest
699 голосов
/ 09 октября 2008

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

Ответы [ 21 ]

719 голосов
/ 09 октября 2008

Под файловой системой файлы представлены в виде инодов (или несколько инодов не уверены)

Файл в файловой системе - это, по сути, ссылка на индекс.
Затем жесткая ссылка просто создает другой файл со ссылкой на тот же базовый индекс.

Когда вы удаляете файл, он удаляет одну ссылку на основной индекс. Индод удаляется (или удаляется / перезаписывается) только после удаления всех ссылок на индекс.

Символическая ссылка - это ссылка на другое имя в файловой системе.

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

Примечание. Жесткие ссылки действительны только в одной файловой системе. Символические ссылки могут охватывать файловые системы, поскольку они являются просто именем другого файла.

413 голосов
/ 07 октября 2009

Хорошая интуиция, которая может помочь при использовании любой консоли Linux (ish).

Создайте два файла:

$ touch foo; touch bar

Введите в них некоторые данные:

$ echo "Cat" > foo
$ echo "Dog" > bar

(На самом деле, я мог бы использовать echo в первую очередь, поскольку он создает файлы, если они не существуют ... но не обращайте на это внимания.)

И, как и ожидалось:

$cat foo; cat bar
Cat
Dog

Давайте создадим жесткие и мягкие ссылки:

$ ln foo foo-hard
$ ln -s bar bar-soft

Посмотрим, что только что произошло:

$ ls -l

foo
foo-hard
bar
bar-soft -> bar

Изменение имени foo не имеет значения:

$ mv foo foo-new
$ cat foo-hard
Cat

foo-hard указывает на индекс, содержимое файла - это не изменилось.

$ mv bar bar-new
$ ls bar-soft
bar-soft
$ cat bar-soft  
cat: bar-soft: No such file or directory

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

Аналогично, если foo удалено, foo-hard все еще содержит содержимое; если bar удалено, bar-soft - это просто ссылка на несуществующий файл.

388 голосов
/ 22 апреля 2015

Как говорится, картинка стоит тысячи слов. Вот как я это представляю:

enter image description here

Вот как мы доберемся до этой картинки:

  1. Создайте имя myfile.txt в файловой системе, которое указывает на новый индекс (который содержит метаданные для файла и указывает на блоки данных, которые содержат его содержимое, то есть текст «Hello, World!»). «:

    $ echo 'Hello, World!' > myfile.txt
    
  2. Создать жесткую ссылку my-hard-link на файл myfile.txt, что означает «создать файл, который должен указывать на тот же индекс, на который указывает myfile.txt»:

    $ ln myfile.txt my-hard-link
    
  3. Создать мягкую ссылку my-soft-link на файл myfile.txt, что означает «создать файл, который должен указывать на файл myfile.txt»:

    $ ln -s myfile.txt my-soft-link
    

Посмотрите, что теперь произойдет, если myfile.txt будет удален (или перемещен): my-hard-link все еще указывает на то же содержимое и, следовательно, не затрагивается, тогда как my-soft-link теперь ничего не указывает. Другие ответы обсуждают плюсы / минусы каждого.

67 голосов
/ 09 октября 2008

Жесткие ссылки полезны, когда исходный файл перемещается. Например, перемещение файла из / bin в / usr / bin или в / usr / local / bin. Любая символическая ссылка на файл в / bin будет нарушена, но жесткая ссылка, являющаяся ссылкой непосредственно на индекс для файла, не будет заботиться.

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

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

Я также думаю, что такие вещи, как mmap (2) и даже open (2) используют ту же функциональность, что и жесткие ссылки, чтобы поддерживать активный индекс файла, так что даже если файл получает unlink (2) ed, индекс остается для разрешения процесса. постоянный доступ, и только когда процесс закрывается, файл действительно исчезает. Это позволяет гораздо более безопасные временные файлы (если вы можете заставить атомы открываться и отменять ссылки, которые могут быть в POSIX API, для которых я не помню, тогда у вас действительно есть безопасный временный файл), где вы можете читать / писать ваши данные без доступа к ним. Что ж, это было верно до того, как / proc дал всем возможность просматривать ваши файловые дескрипторы, но это уже другая история.

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

33 голосов
/ 08 декабря 2014

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

Итак, если у нас есть файл с именем "a" и мы создали жесткую ссылку "b" и символическую ссылку "c", которые все ссылаются на файл "a":

echo "111" > a
ln a b
ln -s a c

Вывод "a", "b" и "c" будет:

cat a --> 111
cat b --> 111
cat c --> 111

Теперь давайте удалим файл «a» и посмотрим, что произойдет с выходными данными «a», «b» и «c»:

rm a
cat a --> No such file or directory
cat b --> 111
cat c --> No such file or directory

Так что случилось?

Поскольку файл "c" указывает на сам файл "a", если файл "a" будет удален, то файлу "c" будет нечего указывать, фактически он также удаляется.

Однако файл "b" указывает на место хранения или на индекс файла "a". Таким образом, если файл «a» удален, он больше не будет указывать на индекс, но, поскольку файл «b» делает это, индекс будет продолжать хранить все содержимое, принадлежащее «a», до тех пор, пока больше не будут жесткие ссылки на него. 1016 *

32 голосов
/ 02 мая 2014

Soft Link :

soft или symbolic - это скорее сокращение к исходному файлу .... если вы удаляете оригинал, ярлык не работает, и если вы удаляете только ярлык, с оригиналом ничего не происходит.

Синтаксис мягкой ссылки : ln -s Pathof_Target_file link

Выход: link -> ./Target_file

Доказательство: readlink link Также в выводе ls -l link вы увидите первую букву в lrwxrwxrwx как l , которая указывает на то, что файл является мягкой ссылкой.

Удаление ссылки: unlink link

Примечание: Если вы хотите, ваша мягкая ссылка может работать даже после перемещения ее в другое место из текущего каталога. Убедитесь, что вы указали абсолютный путь, а не относительный путь при создании мягкой ссылки. т.е. (начиная с / root / user / Target_file, а не ./Target_file)

Жесткая ссылка:

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

Индод (или файл) удаляется только после удаления всех (жестких) ссылок или всех путей к (одному и тому же файлу) индоду.

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

Синтаксис Hard Link : ln Target_file link

Вывод: Будет создан файл со ссылкой на имя с тем же номером инода, что и в Targetfile.

Доказательство: ls -i link Target_file (проверьте их иноды)

Удаление ссылки: rm -f link (Удалить ссылку как обычный файл)

Примечание : Символьные ссылки могут охватывать файловые системы, поскольку они являются просто именем другого файла. Принимая во внимание, что жесткие ссылки действительны только в той же файловой системе.

В символических ссылках есть некоторые функции, жесткие ссылки отсутствуют:

  • Жесткая ссылка указывает на содержимое файла. в то время как Soft link указывает на имя файла.
  • размер жесткой ссылки - это размер содержимого, а мягкая ссылка - с размером имени файла.
  • Жесткие ссылки имеют один и тот же индекс. Мягких ссылок нет.
  • Жесткие ссылки не могут пересекать файловые системы. Софт ссылки делают.
  • Вы сразу же знаете, куда указывает символическая ссылка, когда жестко ссылки, вам нужно изучить всю файловую систему, чтобы найти файлы разделяет один и тот же индекс.

    # find / -inum 517333

    /home/bobbin/sync.sh
    /root/synchro
    
  • жесткие ссылки не могут указывать на каталоги.

Жесткие ссылки имеют два ограничения:

  • Каталоги не могут быть жестко связаны. Linux не позволяет поддерживать ациклическую древовидную структуру каталогов.
  • Жесткая ссылка не может быть создана в файловых системах. Оба файла должны находиться в одних и тех же файловых системах, поскольку разные файловые системы имеют разные независимые таблицы inode (два файла в разных файловых системах, но с одинаковым номером inode будут разными).
29 голосов
/ 09 октября 2008

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

Жесткие ссылки - это дополнительные указатели на индекс, то есть они могут существовать только в том же объеме, что и целевой объект. Дополнительные жесткие ссылки на файл неотличимы от «оригинального» имени, используемого для ссылки на файл.

19 голосов
/ 09 октября 2008

Я бы указал на Википедию:

Несколько баллов:

  • Символьные ссылки, в отличие от жестких ссылок, могут пересекать файловые системы (большую часть времени).
  • Симлинки могут указывать на каталоги.
  • Жесткие ссылки указывают на файл и позволяют ссылаться на один и тот же файл с более чем одним именем.
  • Пока есть хотя бы одна ссылка, данные все еще доступны.
8 голосов
/ 09 октября 2008

Жесткие ссылки очень полезны при создании инкрементных резервных копий. См., Например, rsnapshot . Идея состоит в том, чтобы сделать копию, используя жесткие ссылки:

  • копировать номер резервной копии n в n + 1
  • копировать резервную копию n - 1 в n
  • ...
  • копировать резервную копию 0 в резервную копию 1
  • обновить резервную копию 0 с любыми измененными файлами.

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

5 голосов
/ 09 октября 2008

Я добавляю вопрос Ника: когда жесткие ссылки полезны или необходимы? Единственное приложение, которое мне приходит в голову, в котором символические ссылки не справляются с этой задачей, - это предоставление копии системного файла в среде chroot.

...