Когда бы вы использовали один поверх другого?

Различная семантика между жесткими и мягкими ссылками делает их подходящими для разных вещей.

Жесткие ссылки:

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

Символические ссылки (мягкие ссылки)

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

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

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

В отличие от Windows, они работают на уровне файловой системы, а не на уровне оболочки или приложения, поэтому практически любое приложение будет «следовать» символическим ссылкам, как и ожидалось. ls -alможет использоваться как быстрый способ увидеть, на что указывают символические ссылки.

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

Я не могу вспомнить ситуацию, когда использование жестких ссылок является обычным или даже необходимым, если только вы намеренно не хотите предотвратить удаление файлов или выполняете странную низкоуровневую работу с разделами или другими связанными с файловой системой вещами. РЕДАКТИРОВАТЬ: Есть отличные идеи в других ответах на этот вопрос, хотя!

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

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

Симлинки - это файлы, связывающие другие файлы (как ярлыки Windows), возможно, в той же файловой системе, а может и нет.

РЕДАКТИРОВАТЬ: Я объясню что-то еще. Каждый существующий файл имеет минимум 1 жесткую ссылку. Жесткие ссылки - это способ доступа к содержимому инода файловой системы. В этом примере вы можете получить номер индекса файла ls -iи получить количество жестких ссылок statследующим образом:

$ stat plantilla-disenos.odt 
  File: «plantilla-disenos.odt»
  Size: 12367       Blocks: 32         IO Block: 4096   fichero regular
Device: 803h/2051d  Inode: 319875      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/   d4rio)   Gid: ( 1000/   d4rio)
Access: 2011-02-11 21:36:19.000000000 -0300
Modify: 2010-03-02 23:27:28.000000000 -0300
Change: 2010-04-10 17:46:27.000000000 -0300

Спасибо @geekosaur за эту ссылку:

Ядро должно перезапустить преобразование пути к индексу (обход дерева каталогов), чтобы развернуть символические ссылки, тогда как все жесткие ссылки используют один и тот же индекс. (Вы часто будете видеть это как namei из названия функции ядра, которая сделала это в традиционном Unix.)

и это (отредактировано):

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

ура

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

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

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

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

«жесткие» ссылки имеют один и тот же индекс

$ touch foo
$ ln foo foolink # Creates a hard  link
$ ls -li foo foolink
54996 -rw-r--r-- 2 bsd users 0 2011-12-11 09:06 foo
54996 -rw-r--r-- 2 bsd users 0 2011-12-11 09:06 foolink

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

$ rm foo
$ ls -li foo foolink
ls: cannot access foo: No such file or directory
54996 -rw-r--r-- 1 bsd users 0 2011-12-11 09:06 foolink

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

$ touch foo
$ ln -s foo foolink # Create symlink
$ ls -li foo foolink
55029 -rw-r--r-- 1 bsd users 0 2011-12-11 09:11 foo
55033 lrwxrwxrwx 1 bsd users 3 2011-12-11 09:11 foolink -> foo

Если я отредактирую foo или foolink, все равно останется только один файл, и он будет обновлен.

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

$ rm foo
removed `foo'
$ ls -l foo foolink 
ls: cannot access foo: No such file or directory
lrwxrwxrwx 1 bsd bsd 3 2011-12-11 09:11 foolink -> foo

Жесткие ссылки - это дополнительные записи каталога для того же файла. Это значит

• Все жесткие ссылки на файл должны находиться в одной файловой системе (поскольку запись в каталоге не может указывать на файл в другой файловой системе), но необязательно в одной и той же папке.
• Нет никакой разницы между исходной записью каталога и новой жесткой ссылкой; с точки зрения операционной системы, это всего лишь две записи каталога в одном файле. Файл удаляется только в том случае, если удалены все жесткие ссылки (и, кроме того, не осталось процесса, в котором этот файл все еще открыт).
• Если вы переместите / переименуете «оригинал», если вы не переместите его в другую файловую систему, другие жесткие ссылки не будут затронуты; они все еще указывают на тот же файл.

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

  1. Запишите новый контент в новый файл.
  2. Переименуйте старый файл в имя резервной копии (или, если вы не сохраняете резервные копии предыдущей версии файла, просто удалите его).
  3. Переименуйте вновь записанный файл в имя предыдущего файла.

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

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

Символические ссылки, с другой стороны, хранят имя пути (имя файла - или, скорее, его запись в каталоге - возможно, включая его путь, например /bin/shили subdir/foo.bar) - другого файла. Если путь относительный, он всегда интерпретируется относительно каталога, в котором содержится ссылка. Это означает:

• Символическая ссылка может относиться к файлам в другой файловой системе (даже к файловой системе, которая сама не поддерживает жесткие или программные ссылки, такие как FAT).

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

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

• Если исходный файл заменяется новым файлом с тем же именем (как в сценарии редактора, описанном выше), ссылка ссылается на новый файл.

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

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

HARD LINK (только файлы) против SOFT LINK (файлы или каталоги) против BIND (HARD LINK для каталогов)

_{(источник: freesoftwareservers.com )}

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

Подумайте об этом, если вы «удалили» все с вашего диска, вы можете запустить программное обеспечение для восстановления данных, потому что 1 и 0 все еще там, вы просто удалили все жесткие ссылки. Цель Recovery Software состоит в том, чтобы восстановить Жесткие ссылки, чтобы иметь смысл 0 и 1

Я прочитал отличный "один лайнер", который сделал все это имеет смысл, и я хотел поделиться!

Все файлы в Linux являются «жесткими ссылками» на 0 и 1 на диске. Когда вы создаете данные (0 и 1), ОС создает жесткую ссылку в дереве файлов для ссылки на это место на жестком диске.

Создайте HARD LINK 2 и удалите HARD LINK 1 Исходный файл :

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

Удалите ФАЙЛ (HARD LINK 1), который является СОФТ-ССЫЛКОЙ:

Если вы удалили HARD LINK 1, как вы думаете, SOFT LINK будет работать? Нет, ОС сообщит, что HARD LINK 1 не существует.

Удалить SOFT LINK to HARD LINK:

И наоборот, если вы удалите SOFT LINK, будет ли работать HARD LINK? Да. Пока в ОС имеется один файл HARD LINK, она будет сообщать, что заливка не была удалена.

- Также стоит изучить / отметить BIND, способ BIND двух каталогов, такой как символическая ссылка двух каталогов, но он прозрачен для ОС (ОС могут определить, когда у вас есть Symlink, а у некоторых есть правила относительно погоды, по которым они могут следовать по Symlinks). Он использует Mount, а не LS и может быть настроен через FSTAB.

Что такое крепление BIND

Жесткая ссылка будет сохранять файл на диске до тех пор, пока все жесткие ссылки на него, даже первые («имя файла» - технически жесткая ссылка), не будут удалены. Мягкую ссылку можно оставить «висячей», пока не будет заменен файл, на который она указывает (s / ed).

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

Я музыкант, и поэтому у меня есть много-много-много аудио-файлов разных видов на нескольких жестких дисках, прикрепленных к моему Mac. Терабайт стоит. У меня они в основном очень хорошо организованы с каталогами символических ссылок, так что я могу найти их по издателю контента, стилю / звуку и другим критериям, основанным на том, как я думаю в то время. К сожалению, одна программа, которую я использую, Ableton Live, совершенно не в состоянии просматривать псевдонимы или символические ссылки из своего файлового браузера. Единственное решение, которое я нашел, - это создать жесткие ссылки на каталоги, которые я хочу видеть, и тогда все будет отлично работать.

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