Существуют два основных ограничения жестких ссылок:
Таким образом, символические ссылки были введены, чтобы обойти ограничения жестких ссылок. Итак, вопрос в том, нужны ли еще жесткие ссылки? Может ли быть ситуация, когда они более полезны?
Жесткие ссылки помогают нам организовать нашу файловую систему гораздо более гибко. По сути, жесткие ссылки позволяют нам взять один файл и иметь его в нескольких местах в файловой системе одновременно. Подумайте о сценарии, где вы фотограф и у вас много фотографий (это пример из моей жизни!). Вы можете организовать их по людям, которые появляются в них, потому что иногда люди просят вас сфотографировать их. Но вы также можете организовать их по месту и дате. Нет никакого реального способа вложить эти три вещи, они - полностью отдельные оси организации. Таким образом, вы можете создать три разные иерархии для этих трех разных вещей, и каждая фотография должна присутствовать во всех трех, без необходимости хранить каждую фотографию три раза. Это магия жестких ссылок. Отключите символические ссылки, нам не нужно беспокоиться о том, где находится "настоящий файл", потому что все они - настоящий файл. Мы можем удалять и перемещать по желанию, поскольку файл будет сохраняться до тех пор, пока на него больше не будет никаких ссылок, и удаляется при удалении последней жесткой ссылки. Это просто и не требует от вас очень много отслеживать.
Содержимое файла не будет очищено до тех пор, пока все жесткие ссылки (да, все имена файлов являются жесткими ссылками, даже первые) не будут удалены и файл не будет закрыт. Поэтому он может быть полезен, когда файл требуется в нескольких местах, но может быть удален из любого из них в любое время, например, между ~/Downloads/coolsong.mp3 и ~/Music/Cool Song.mp3 .
Одно не очень важное преимущество жесткой ссылки перед символической ссылкой состоит в том, что когда она достигает inode для жесткой ссылки, ядро не имеет дальнейшей обработки для доступа к файлу. Когда он встречает символическую ссылку, ядро должно прочитать значение ссылки и продолжить обход структуры каталогов, прежде чем попасть в индекс для файла. Это занимает больше времени, хотя разница не всегда легко измеряется. Это становится действительно забавным, когда один из элементов значения символической ссылки сам является символической ссылкой.
Есть несколько причин для жестких ссылок
Так что одна из причин использования жестких ссылок - возможно, сэкономить много места ...
Вы можете добавить к любой из ссылок, и данные отправляются в общий файл. Вы также можете добавить один файловый дескриптор, читая другой (например, с помощью tail -f)
Многие из приведенных здесь примеров действительны, но одинаково хорошо работают с мягкими ссылками (например, проблема "нужен один файл в нескольких местах").
Хорошим примером того, где жесткие ссылки действительно полезны, является программа резервного копирования Dirvish:
Dirvish - это быстрая дисковая вращающаяся сетевая система резервного копирования.
С Dirvish вы можете поддерживать набор полных образов ваших файловых систем с автоматическим созданием и истечением срока действия. Хранилище резервных копий как машина времени для ваших данных.
Dirvish создает резервные копии на уровне файловой системы (то есть копирует файлы, но не создает образы), копируя файлы в отдельную (резервную) файловую систему (например, жесткий диск USB). Каждый раз, когда вы делаете резервную копию, dirvish создает отдельную, полную копию дерева каталогов для сохранения.
Хитрость заключается в том, что если dirvish обнаруживает, что уже существует более старая резервная копия дерева, которое вы сохраняете, он автоматически повторно использует файлы, которые не были изменены, создавая жесткую ссылку в новом дереве на файл в старом дереве.
Таким образом, каждая резервная копия является полной, автономной копией дерева каталогов, но в то же время только измененные файлы фактически занимают место в файловой системе. Другими словами, вы получаете преимущества инкрементного резервного копирования (экономия места) и полного резервного копирования (простое извлечение) одновременно.
Это возможно только потому, что жесткие ссылки полностью прозрачны для инструментов пользовательского пространства.
Это, вероятно, также будет работать с символическими ссылками (хотя у вас могут возникнуть проблемы при резервном копировании данных, в которых используются символические ссылки), но одно преимущество, которое возможно только для жестких ссылок:
Если вы хотите выбросить старые резервные копии, вы можете просто удалить соответствующее дерево каталогов резервных копий. Файлы, связанные только с этим деревом, автоматически удаляются файловой системой (поскольку удаляется их последняя жесткая ссылка), но файлы, которые также появляются в других копиях, остаются на диске.
Скажем, один полезный случай - когда у вас есть программа (или сценарий), которая должна загрузить большой временный архив, и после распаковки ваша программа немедленно его удалит.
Если по какой-то причине вы хотите сохранить этот tar-архив для будущего использования, лучше всего использовать ln /tmp/tarball.tgz ~ пока tar-файл еще загружается. Тогда вам не нужно ничего делать.
Когда загрузка закончится, и даже после того, как ваша программа удалит «оригинальную», точная копия все равно должна быть в вашем домашнем каталоге.
Я использую «Жесткие ссылки» для резервного копирования некоторых моих «HowTos» и фрагментов
У меня есть каталог с именем «Shared Docs» в моем пользователе /root. В этом каталоге у меня есть «жесткие ссылки» на мои советы, подсказки, фрагменты, инструкции, которые находятся в соответствующих каталогах; php, mysql, css, regex, формулы, linux и т. д. Хранить их в «одном месте» намного проще в использовании, обновлять их, чем прыгать по моим документам / каталогам в поисках документов, которые я часто использую.
Давным-давно я использовал символические ссылки. Я бы искренне сделал резервную копию этой общей папки «Shared Docs» на моем сервере. Проблема заключается в том, что символические ссылки или «мягкие ссылки», если они скопированы (cp -auv) или скопированы и скопированы, ТОЛЬКО выполняют резервное копирование или копируют «ссылку», а НЕ содержимое документа. Поэтому мне придется пройтись по каталогам и скопировать каждый из 2 дюжин файлов с их фактического местоположения.
С помощью HARD LINKS я могу копировать, tar, rsync каталог «Shared Docs» и на самом деле делать резервные копии этих широко рассредоточенных документов с уверенностью, содержимое фактически резервируется. Это действительно отстойно для меня, когда я понял, что я копирую 0 кусков «файлов ссылок», а не информации.
Недостатком использования «жестких ссылок» является то, что выполнение ls для каталога не дает вам указания на то, что файл «связан» с другим файлом или где этот файл может сосуществовать. Есть способы найти их, но я говорю, что это неочевидно с помощью простых ls -l -> указывает на ... Поэтому я обычно добавляю примечание в начало документа, указывающее, с каким каталогом / файлами «этот файл» «обменивается»
Landis.
