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

https://stackoverflow.com/questions/185899

06-07-2019
|

Вопрос

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

Решение

Под файлами файловой системы представлены inode (или несколько inode не уверены)

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

Когда вы удаляете файл, он удаляет одну ссылку на основной индекс. Индод удаляется (или удаляется / перезаписывается) только после удаления всех ссылок на индекс.

Символическая ссылка - это ссылка на другое имя в файловой системе.

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

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

Другие советы

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

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

$ touch foo; touch bar

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

$ echo "Cat" > foo
$ echo "Dog" > bar

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

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

$cat foo; cat bar
Cat
Dog

Давайте создадим жесткие и мягкие ссылки:

$ ln foo foo-hard
$ ln -s bar bar-soft

Давайте посмотрим, что только что произошло:

$ ls -l

foo
foo-hard
bar
bar-soft -> bar

Изменение имени foo не имеет значения:

$ mv foo foo-new
$ cat foo-hard
Cat

foo-hard указывает на inode, содержимое файла - это не изменилось.

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

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

Аналогичным образом, если foo удален, foo-hard по-прежнему содержит содержимое; если bar удален, bar-soft - это просто ссылка на несуществующий файл.

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

введите описание изображения здесь

Вот как мы доберемся до этой картинки:

<Ол>

Создайте имя myfile.txt в файловой системе, которое указывает на новый индекс (который содержит метаданные для файла и указывает на блоки данных, которые содержат его содержимое, т.е. текст "Привет, мир!":

$ echo 'Hello, World!' > myfile.txt

Создайте жесткую ссылку my-hard-link на файл myfile.txt , что означает " создать файл, который должен указывать на тот же индекс myfile.txt указывает на "

$ ln myfile.txt my-hard-link

Создайте мягкую ссылку my-soft-link на файл myfile.txt , что означает " создать файл, который должен указывать на файл < код> myfile.txt & Quot;

$ 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), используют ту же функциональность, что и жесткие ссылки, чтобы поддерживать активность индексного дескриптора файла, так что даже если файл будет отключен (2), индексный дескриптор останется, чтобы процесс мог продолжать доступ, и только после закрытия процесса файл действительно исчезает.Это позволяет создавать гораздо более безопасные временные файлы (если вы можете автоматически открывать и отключать связь, для чего может быть POSIX API, я не помню, тогда у вас действительно есть безопасный временный файл), где вы можете читать/записывать ваши данные, при этом никто не сможет получить к ним доступ.Ну, это было верно до того, как /proc дал всем возможность просматривать ваши файловые дескрипторы, но это уже другая история.

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

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

Итак, если у нас есть файл с именем " a " и создать жесткую ссылку " b " и символьная ссылка «c»; которые все ссылаются на файл " а "

echo "111" > a
ln a b
ln -s a c

Вывод «a», «b» и «c»; будет:

cat a --> 111
cat b --> 111
cat c --> 111

Теперь давайте удалим файл " a " и посмотрите, что произойдет с выходными данными «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 " указывает на место хранения или inode файла "a". Так что если файл " a " удаляется, то это больше не будет указывать на индекс, а потому что файл " b " В этом случае индекс будет продолжать хранить все содержимое, принадлежащее & a; quot; a " пока более жесткие ссылки не указывают на это больше.

Мягкая ссылка:

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

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

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

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

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

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

Жесткая ссылка:

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

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

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

Синтаксис жесткой ссылки: ln Target_file link

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

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

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

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

Символические ссылки имеют некоторые особенности, которых нет у жестких ссылок:

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

# find / -inum 517333
```
/home/bobbin/sync.sh
/root/synchro
```
жесткие ссылки не могут указывать на каталоги.

Жесткие ссылки имеют два ограничения:

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

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

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

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

Несколько моментов:

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

Жесткие ссылки очень полезны при выполнении инкрементного резервного копирования.Видеть снимок, например.Идея состоит в том, чтобы скопировать с использованием жестких ссылок:

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

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

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

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

Также:

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

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

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

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

От 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"

Жесткая ссылка

А жесткая ссылка это представление файловой системы файла, с помощью которого более одного пути ссылается на один файл в том же объеме.

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

mklink /H Link_name target_path

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

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

перекресток

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

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

Части, выделенные жирным шрифтом в разделе жестких ссылок и разделе соединения, показывают основную разницу между ними.

Команда для создания соединения в Windows, перейдите туда, где должна быть создана ссылка, и затем введите:

mklink /J link_name target_path

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

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

Запись каталога является ссылкой на структуру:

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

ino - это номер inode, имя - это имя файла, структура inode может быть похожа на & # 65306;

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

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

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

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

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

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

$ find -L . -samefile f6 

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

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

$ find . -xdev -samefile f6

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow