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

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

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

Hardlinks работают даже на более низком уровне. hardlink является фактической, физической on-the-filesystem-level записью каталога файла. Технически, запись каталога является hardlink, таким образом каждый файл имеет по крайней мере один hardlink в каталоге где-нибудь. Hardlinks не являются отдельными из файла, на который они указывают; если файл имеет несколько hardlinks в различных каталогах, удаляя hardlink с утилитами как rm действительно не удалит файл, пока всех hardlinks не не стало.

Я не могу думать о ситуации, где использование hardlinks является общим, или даже необходимое, если Вы намеренно не хотите препятствовать файлам то, чтобы быть удаленным или делаете некоторую странную работу низкого уровня с разделами или другими связанными с файловой системой вещами.Править: Существуют прекрасные идеи в других ответах на этот вопрос, хотя!

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

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

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

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

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

Жесткие ссылки являются просто ссылками на те же дисковые пространства, thath, 'почему' Вы не можете hardlink что-то в другой файловой системе.

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

Править: Я объясню что-то больше. Каждый файл, который существует, имеет минимум 1 жесткой ссылки. Жесткие ссылки являются способом получить доступ к содержанию inode файловой системы. Можно получить inode количество файла с ls -i, и получите количество hardlinks с 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 для этой ссылки:

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

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

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

Удачи

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

"твердые" ссылки совместно используют тот же inode

$ 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

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

$ 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

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

$ 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

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

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

$ 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 (только файлы) vs SOFT LINK (файлы или каталоги) vs BIND (HARD LINK для каталогов)

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

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

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

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

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

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

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

Удалить ФАЙЛ (ЖЕСТКАЯ ССЫЛКА 1), с которым МЯГКАЯ ССЫЛКА связана:

Если вы удалили ЖЕСТкую ССЫЛКУ 1, как вы думаете, МЯГКАЯ ССЫЛКА будет работать? Нет, ОС сообщит, что HARD LINK 1 не существует.

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

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

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

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

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

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

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