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

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

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

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

  $ echo 'Hello, World!' > myfile.txt
  

• Создайте жесткую ссылку my-hard-link в файл myfile.txt, что означает "создать файл, который должен указывать на тот же индекс, что myfile.txt указывает на":

  $ ln myfile.txt my-hard-link
  

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

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

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

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

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

$ touch blah1; touch blah2

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

$ echo "Cat" > blah1
$ echo "Dog" > blah2

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

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

$cat blah1; cat blah2
Cat
Dog

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

$ ln blah1 blah1-hard
$ ln -s blah2 blah2-soft

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

$ ls -l

blah1
blah1-hard
blah2
blah2-soft -> blah2

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

$ mv blah1 blah1-new
$ cat blah1-hard
Cat

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

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

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

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

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

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

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

Говоря о том, что восстановление файла, открытого в процессе A, но не привязанного к файловой системе, вращается вокруг жестких ссылок для воссоздания ссылок 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" указывает на место хранения или inode файла "a" . Поэтому, если файл "a" удаляется, то он больше не будет указывать на индексный дескриптор, но поскольку файл "b" делает, inode будет продолжать хранить содержимое, принадлежащее "a" , пока больше не будет жестких ссылок на него.

Soft Link:

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

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

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

Доказательство: readlink link для ls -l 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 (проверьте их inode)

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

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

Символические ссылки имеют некоторые особенности, которые отсутствуют: жесткие ссылки:

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

• Вы сразу же знаете, куда указывает символическая ссылка, в то время как с жесткими ссылками вам нужно исследовать всю файловую систему, чтобы найти файлы с одинаковым индексом.

  # find / -inum 517333

  /home/bobbin/sync.sh
  /root/synchro
  

• твердые чернила -l не могут указывать на каталоги.

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

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

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

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

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

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

Несколько точек:

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

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

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

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

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

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

• Жесткие ссылки должны присутствовать на одном устройстве.
• Мы не можем создать жесткие ссылки на каталоги.
• Количество псевдонимов исходного файла есть. Когда имя удаляется, содержимое также удаляется.

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

В качестве символической ссылки (также называемой soft link) не ссылается непосредственно на индексный дескриптор, а на имя файла. Основной недостаток заключается в том, что когда Исходный файл удаляется, символическая ссылка становится недействительной и больше не работает.

Некоторая информация об Inode:

Linux хранит административные данные о файлах в inodes. Каждый файл в Linux имеет inode и в inode хранится важная информация о файле:

• Блок данных, в котором хранятся содержимое файла
• Дата создания, доступа и изменения
• Права доступа
• Владельцы файлов

Только одна важная часть информации не хранится в inode: имя. имена хранятся в каталоге, и каждое имя файла знает, к какому индексу он должен обратиться доступ к дополнительной информации о файлах. Интересно знать, что инод не знает имя которого оно имеет; он просто знает, сколько имен связано с inode. Эти имена называются жесткими ссылками. Когда вы создаете файл, вы даете ему имя. В принципе, это имя является жесткой ссылкой.

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

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

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

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

также:

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

В записи каталога есть ссылка structrue:

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 может выглядеть как:

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

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

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

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

   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 может выглядеть как:

   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 */

Из 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 поддерживает другой тип ссылки, называемый соединением. MSDN определяет его следующим образом:

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

Полужирные части в секции жесткой связи и секции соединения показывают основное различие между ними.

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

mklink /J link_name target_path

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

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

Добавляя все приведенные выше ответы, различие в поиске файла hardlink и softlink можно понять ниже:

У меня есть файл 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

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

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

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

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

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

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