В чем разница между символической ссылкой и жесткой ссылкой?

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

Под файловой системой файлы представлены inode. (Или это несколько inode? Не уверен.)

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

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

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

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

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

Хорошая интуиция, которая может помочь при использовании любой консоли 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 указывает на inode, содержимое файла - это не изменилось.

$ 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это просто ссылка на несуществующий файл.

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

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

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время как теперь ничего не указывает. Другие ответы обсуждают плюсы / минусы каждого.

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

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

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

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

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

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. Удаление одного из них по-прежнему сохраняет в порядке.

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

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

Синтаксис жесткой ссылки :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 будут разными).

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

Итак, если у нас есть файл с именем «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», до тех пор, пока больше не будет жестких ссылок на него.

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

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

Я хотел бы указать вам на Википедию:

• Символьная ссылка
• Жесткая ссылка

Несколько моментов:

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

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

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

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

Жесткая ссылка и мягкая ссылка может быть легко объяснена этим изображением.

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

Из MSDN ,

Символьная ссылка

Символическая ссылка - это объект файловой системы, который указывает на другой объект файловой системы. Указываемый объект называется целью.

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

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

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

Пример абсолютной символической ссылки

X: "C:\alpha\beta\absLink\gamma\file"
Link: "absLink" maps to "\\machineB\share"
Modified Path: "\\machineB\share\gamma\file"

Пример относительных символических ссылок

X: C:\alpha\beta\link\gamma\file
Link: "link" maps to "..\..\theta"
Modified Path: "C:\alpha\beta\..\..\theta\gamma\file"
Final Path: "C:\theta\gamma\file"

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

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

Чтобы создать жесткую ссылку в Windows, перейдите туда, где должна быть создана ссылка, и введите следующую команду:

mklink /H Link_name target_path

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

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

узловой

NTFS поддерживает другой тип ссылки, называемый junction. MSDN определяет это следующим образом:

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

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

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

mklink /J link_name target_path

Также:

1. Производительность чтения жестких ссылок лучше, чем символических ссылок (микро-производительность)
2. Символические ссылки могут быть скопированы, с контролем версий, и т.д. Другими словами, они являются фактическим файлом. С другой стороны, жесткая ссылка - это что-то на несколько более низком уровне, и вы обнаружите, что по сравнению с символическими ссылками меньше инструментов, которые предоставляют средства для работы с жесткими ссылками как с жесткими ссылками, а не с обычными файлами.

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

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

То, что вы считаете обычным «файлом», на самом деле две разные вещи: данные файла и запись в каталоге. Когда вы создаете жесткую ссылку для файла, вы фактически создаете вторую запись каталога, которая ссылается на те же данные. Обе записи каталога имеют одинаковую функциональность; каждый из них может быть использован для открытия файла, чтобы прочитать его. Таким образом, у вас нет «файла плюс жесткая ссылка», у вас есть «данные файла с двумя записями каталога». То, что вы считаете удалением файла, фактически удаляет запись каталога, и когда удаляется последняя запись каталога для данных, то и сами данные также удаляются. Для обычных файлов, которые имеют только одну запись каталога, удаление записи каталога приведет к удалению данных как всегда. (Пока файл открыт, ОС создает временную ссылку на файл,

В качестве примера создайте файл A.txt, жесткую ссылку B.txt и удалите A.txt. Когда вы создали A.txt, были созданы некоторые данные и запись каталога A.txt. Когда вы создали жесткую ссылку, была создана другая запись каталога B.txt, указывающая на те же самые данные. При удалении A.txt у вас все еще остаются все данные и одна запись каталога B.txt, точно так же, как если бы вы сначала создали файл B.txt.

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

Запись в каталоге является ссылкой на структуру:

struct dentry{
    ino_t ino;
    char  name[256];
}

ino - это номер inode, имя - это имя файла, структура inode может быть такой:

struct inode{
      link_t nlink; 
      ...
}

например, вы создали файл / 1, запись в каталоге может выглядеть так:

struct dentry{
     ino_t ino; /* such as 15 */
     char  name[256]; /* "1" */
} 

структура inode может выглядеть так:

   struct inode{ /* inode number 15 */
         link_t nlink; /* nlink = 1 */
         ...
    }

затем вы создаете жесткую ссылку (может быть / 100), запись в каталоге может выглядеть так:

  struct dentry{
     ino_t ino; /* 15 */
     char  name[256]; /* 100 */
  }

структура inode может выглядеть так:

   struct inode{ /* inode numebr 15 */
         link_t nlink; /* nlink = 2 */
         ...
    }

затем вы создаете символическую ссылку (может быть / 200) на файл 1, запись в каталоге может выглядеть так:

  struct dentry{
        ino_t ino; /* such as 16 */
        char  name[256]; /* "200" */
  }

структура inode может выглядеть так:

   struct inode{ /* inode number 15 */ 
         link_t nlink; /* nlink = 2 */
         ...
    }

   struct inode{ /* inode number 16 */
         link_t nlink; /* nlink = 1 */
         ...
    } /* the data of inode 16 maybe /1 or 1 */

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

У меня есть файл f6в моем текущем каталоге, а также каталог с именемt2 .

Файл назван f1и ./t2/f2является символической ссылкой наf6 .

Файл с именем f7и ./t2/f8жесткие ссылкиf6 .

Чтобы найти как мягкую, так и жесткую ссылку, мы можем использовать:

$ find -L . -samefile f6 

> ./f1
> ./f6
> ./f7
> ./t2/f2
> ./t2/f8

Чтобы найти только жесткую ссылку, мы можем использовать:

$ find . -xdev -samefile f6

> ./f6
> ./f7
> ./t2/f8

Поскольку жесткие ссылки могут быть созданы в одной и той же файловой системе, мы можем искать все жесткие ссылки без -Lиспользования опций (с-xdev опцией) в одной файловой системе / точке монтирования. Это сохраняет ненужный поиск в разных точках монтирования.

Таким образом, поиск по жесткой ссылке несколько быстрее, чем поиск по программным ссылкам (пожалуйста, исправьте, если я ошибаюсь или не ясен).

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

Мои два цента на использование:

Мягкие ссылки могут использоваться для сокращения длинных имен путей, то есть:

ln -s /long/folder/name/on/long/path/file.txt /short/file.txt

Изменения /short/file.txtбудут применены к исходному файлу.

Жесткие ссылки могут использоваться для перемещения больших файлов:

$ ls -lh /myapp/dev/
total 10G
-rw-r--r-- 2 root root 10G May 22 12:09 application.bin

ln /myapp/dev/application.bin /myapp/prd/application.bin

Мгновенное копирование в другую папку, и исходный файл (вкл /myapp/dev) можно перемещать или удалять, не касаясь файла на/myapp/prd

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

Однажды я загрузил программное обеспечение в папку Downloadsдля установки. После этого sudo make installнекоторые исполняемые файлы были cpдобавлены в локальную папку bin. Здесь cpсоздается жесткая ссылка . Я был счастлив с программным обеспечением, но вскоре понял, что Downloadsэто не очень хорошее место в долгосрочной перспективе. Поэтому я mvпереместил папку с программным обеспечением в sourceкаталог. Ну, я все еще могу запускать программное обеспечение, как и раньше, не беспокоясь о каких-либо целевых ссылках, как в Windows. Это означает, что жесткая ссылка находит непосредственно inode и другие файлы вокруг.

В этом ответе, когда я говорю файл, я имею в виду местоположение в памяти

Все сохраненные данные хранятся в памяти с использованием структуры данных, называемой inode. Каждый inode имеет inodenumber. Номер inode используется для доступа к inode. Все жесткие ссылки на файл могут иметь разные имена, но иметь одинаковый номер inode. Поскольку все жесткие ссылки имеют один и тот же inodenumber (который обеспечивает доступ к одному и тому же inode), все они указывают на одну и ту же физическую память.

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

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