Intereting Posts
Есть ли что-то вроде командной консоли Linux под ключ? systemd.unit `RequiresMountsFor =` vs `ConditionPathIsDirectory =` Как rsync chroot без нарушения символических ссылок? Файл Bash: нет такого файла или каталога Не удалось синхронизировать клиент NTP v4 с сервером Windows AD Почему утилита переименования на Debian / Ubuntu отличается от той, которая используется в других дистрибутивах, например CentOS? PF и типы NAT (трансляция сетевых адресов) Параметры dd-стиля для сценария bash Ошибка компоновки клавиатуры в окне входа в систему после блокировки экрана Найти использование дисковых папок с символическими ссылками Различия ч / б аппаратного времени и системного времени Сохранение владельца / группы по предоставленным OS X акциям CIFS Как читать из последовательного порта, не используя его ресурс? DNS-сервер для внесения черного списка тонны доменов, а также некоторых TLD Модемы и модальные редакторы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

EDIT: Я объясню еще кое-что. Каждый существующий файл имеет минимум 1 жесткую ссылку. Жесткие ссылки – это способ доступа к содержимому индексного дескриптора файловой системы. Вы можете получить номер inode файла с 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 за эту ссылку:

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

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

 $ 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 

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

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

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

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

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

ПРОСМОТРЕТЬ ЭТО ИЗОБРАЖЕНИЕ ПЕРЕД ЧТЕНИЕМ POST

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

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

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

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

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

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

Удалить FILE (HARD LINK 1), SOFT LINKed для:

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

Удалите SOFT LINK к HARD LINK:

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

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

Что такое BIND mount

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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