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

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

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

$ touch blah1; touch blah2

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

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

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

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

$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 указывает на индекс, содержимое файла-это не было изменено.

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

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

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

Вот как мы подходим к этой картине:

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

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

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

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

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

Мягкая Связь:

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

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

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

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

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

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

Жесткая Связь:

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

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

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

Жесткая Связь синтаксис: ln Target_file link

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

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

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

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

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

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

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

На жестком диске имеется множество секторов.

Предположим, файл начинается с индекса (сектора) 4001 и заканчивается на 5000. Файл " / export / home / john / mail.doc "

Тогда: 1. Жесткая ссылка на " почту.doc", который называется "hardLinkToMail", содержит значение: "4001". 2. Мягкая ссылка на " почту.док" который называется "softLinkToMail" содержит значение: "/ export / home / john / mail.док".

В 1) жесткая ссылка может указывать только на один и тот же диск. Он не может указывать на другой диск. Все приводы имеют индекс значения "4001", как может жесткая связь различать все диски? Какой из дисков "4001"?

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

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

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

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

• символическая ссылка
• жесткая связь

Несколько пунктов:

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

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

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

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

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

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

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

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

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

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

1. блок данных, в котором хранится содержимое файла
2. Дата создания, доступа и модификации
3. разрешения
4. файл владельцы

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

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

Также:

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

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

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

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

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

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

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

Из 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"

Жесткая связь

A hard link - это представление файловой системы файла, с помощью которого несколько путей ссылаются на один файл в одном томе.

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

mklink /H Link_name target_path

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

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

Переход

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

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

Выделенные жирным шрифтом части в разделе жесткого соединения и разделе соединения показывают основное различие между ними.

Команда для создания соединения в windows перейдите к месту создания соединения и введите:

mklink /J link_name target_path

Запись каталога-это ссылка на structrue:

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

Ino-это номер индекса, имя-это имя файла, структура индекса может быть похожа на:

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

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

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

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

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

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

$ find -L . -samefile f6 

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

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

$ find . -xdev -samefile f6

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

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

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

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

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

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

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

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

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

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

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

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

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