Почему жесткие ссылки можно делать только в пределах одной файловой системы
Я знаю, что такое жесткие ссылки, но зачем мне их использовать? В чем полезность жесткой ссылки?
Основным преимуществом жестких ссылок является то, что по сравнению с мягкими ссылками нет размера или скорости. Мягкие ссылки - это дополнительный уровень косвенности поверх обычного доступа к файлам; ядро должно разыменовать ссылку, когда вы открываете файл, и это занимает немного времени. Ссылка также занимает небольшое место на диске для хранения текста ссылки. Эти штрафы не существуют с жесткими ссылками, потому что они встроены в саму структуру файловой системы.
Лучший способ узнать это:
-i Вариант ls делает это даст вам номер инодов файла. В системе, где я подготовил приведенный выше пример, я оказался в каталоге с номером индекса 1069765, но конкретное значение не имеет значения. Это просто уникальное значение, которое идентифицирует определенный файл / каталог.
Это говорит о том, что когда мы заходим в подкаталог и смотрим на другую запись в файловой системе .. , она имеет тот же номер инода, что и раньше. Этого не происходит, потому что оболочка интерпретирует .. для вас, как это происходит с MS-DOS и Windows. В файловых системах Unix .. это настоящая запись каталога; это жесткая ссылка, указывающая на предыдущий каталог.
Жесткие ссылки - это сухожилия, которые связывают каталоги файловой системы. Когда-то в Unix не было жестких ссылок. Они были добавлены, чтобы превратить исходную плоскую файловую систему Unix в иерархическую файловую систему.
В системах Unix также довольно часто несколько разных команд реализуются одним и тем же исполняемым файлом. Похоже, это больше не относится к Linux, но к системам, которые я использовал в прошлом cp , mv и rm все они были одинаково исполняемыми. Это имеет смысл, если вы подумаете об этом: когда вы перемещаете файл между томами, это фактически копия, за которой следует удаление, поэтому mv уже пришлось реализовать функции двух других команд. Исполняемый файл может выяснить, какую операцию предоставить, поскольку ему передается имя, по которому он был вызван.
Другим примером, распространенным во встроенных Linux-системах, является BusyBox , один исполняемый файл, который реализует десятки команд.
Следует отметить, что в большинстве файловых систем пользователям запрещается делать жесткие ссылки на каталоги. . И .. запись автоматически управляется с помощью кода файловой системы, которая обычно является часть ядра. Ограничение существует, потому что возможно вызвать серьезные проблемы с файловой системой, если вы не будете осторожны с тем, как создавать и использовать жесткие ссылки на каталоги. Это одна из многих причин существования мягких ссылок; они не несут такой же риск.
О «Ссылка также занимает небольшое количество места на диске, чтобы удерживать текст ссылки». В современных файловых системах дополнительное пространство не используется для хранения пути ссылки, поскольку сама запись каталога используется для его хранения, по крайней мере, если имя не слишком длинное, чтобы соответствовать. Это называется "быстрые символические
Я хотел бы добавить, что некоторые приложения не знают, как обрабатывать мягкие (sym) ссылки, и, таким образом, жесткие ссылки могут быть полезны, чтобы избежать избыточности при настройке их, ссылаясь на те же файлы данных / конфигурации. Примером является ioquake3, который не может следовать за символически связанными файлами pk3, но может следовать за жестко связанными файлами pk3.
Кроме того, если вы удалите цель символической ссылки, файл исчезнет, а символическая ссылка будет повреждена. Проблема, которая не существует с жесткой ссылкой.
Одно из применений жестких ссылок, которое чрезвычайно полезно, - это добавочное резервное копирование в сочетании с rsync. Это экономит много места и делает процедуру восстановления действительно простой. Я использую этот подход для резервного копирования на моих серверах.
Потратьте некоторое время, чтобы прочитать это объяснение .
Если после прочтения этой страницы википедии у вас возник вопрос «зачем мне их использовать», то вы не понимаете, что такое жесткие ссылки.
Ссылка является запись каталога , который указывает на блоки на диске. Другими словами, каждый файл в вашей системе имеет хотя бы одну ссылку. Когда вы rm файл фактический системный вызов unlink() . Удаляет запись каталога. Блоки на диске не изменились, но ссылка исчезла, поэтому файл исчез из списка каталогов.
Вы лично никогда не можете использовать жесткие ссылки, но они есть во всей вашей системе. Например:
Вы можете видеть это bunzip2 , bzcat и bzip все используют один и тот же индекс. По сути, это один файл с тремя именами. У вас может быть три копии файла, но почему? Это только израсходовало бы дисковое пространство без необходимости.
Но есть также несколько символических ссылок /bin , я думаю, это один из источников путаницы. Почему иногда исполняемые файлы будут символическими, а иногда - жесткими?
Есть любое количество применений. Я использую их для создания файловых блокировок. Системный вызов link (2) является атомарным, в отличие от большинства других системных вызовов.
Другое использование в rsnapshot, где резервные копии создаются с использованием жестких ссылок для уменьшения объема дискового пространства. Если файл не изменился, то файл жестко связан с более старыми экземплярами файла, а измененные файлы копируются заново.
Я также использую их для замены файлов конфигурации на серверах: rm file.cfg && ln ~/tmp/file.cfg file.cfg затем файлы ~ / tmp / * можно безопасно удалить.
Чтобы добавить к нескольким хорошим обсуждениям, уже присутствующим .
- Способ, которым доступ к ресурсам для программ реализован в Unix (т. Е. «Все является файлом» ), означает, что инфраструктура для обработки множественных ссылок на файл требуется для работы ОС вообще, поэтому здесь нет дополнительных затрат.
- То, как каталоги были реализованы в исходных файловых системах Unix (т. Е. Список (inode, name) пар фиксированного формата означает, что в файловой системе нет дополнительных затрат на наличие жестких ссылок (ну, пока мы предотвращаем циклы, не допуская жесткую ссылку на каталоги (кроме . и .. (разве это начинает кому-то еще нравиться?)))
поэтому мы получаем их бесплатно.
Я, вероятно, должен охватить сценарий ловушек жестких ссылок. Жесткая ссылка будет представлять собой тот же файл с другим именем и / или другим местоположением, если существует исходный связанный файл . Неправильно даже думать о файле как о «оригинальном»: оба являются самостоятельными записями каталога, и оба (или более) - все равные одноранговые узлы. Для долгоживущих файлов это может быть благословением, но если одна из пары будет удалена и затем создана, даже с тем же именем и содержимым, файлы будут разделены.
Предположим, вы создали жесткую ссылку /foo/myfile на /repo/myfile . Оба указателя на одни и те же данные файла; измените одно, другое изменится. Но предположим, что /repo случается с хранилищем Git. Если вы проверите ветку, которая не содержит myfile в нем, /repo/myfile удаляется. В этот момент /foo/myfile становится простой копией /repo/myfile , как бы в тот момент другая пара не была связана. Легко даже не заметить, когда вы переключаетесь между ветвями, что файл репертуара изменяется, но, когда вы извлекаете оригинальную ветку, новый файл /repo/myfile создан Git. Если бы вы не обратили внимания, вы бы удивились, почему два файла теперь имеют разное содержимое, хотя это легко понять, так как отношения жестких ссылок между файлами не имеют представления об их именах. Напротив, мягкая ссылка выживет в этом цикле удаления-создания.
С другой стороны, программное обеспечение, использующее жесткие ссылки, четко осознает это, и Git является ярким примером. Git клонирует репозиторий в той же файловой системе практически бесплатно, потому что он использует жесткие ссылки по умолчанию вместо копирования файлов. Для Git жесткая ссылка является идеальным вариантом использования, потому что его файлы объектов и пакетов никогда не меняются, поэтому один клон репозитория никогда не изменит другой (Git знает, что не нужно жестко связывать изменяемые файлы), и любой из клонов может быть удаляется без каких-либо мер предосторожности: нет необходимости отслеживать, какой из них является «оригинальным» и действительно содержит файлы: любая из жестких ссылок является равноправным партнером и «содержит» полный файл. Мягкие ссылки просто не будут работать здесь.
Еще одним преимуществом жесткой ссылки является то, что любая ссылка может быть перемещена без нарушения доступа к содержимому файла. При использовании мягких ссылок перемещение исходного файла приводит к зависанию всех мягких ссылок.
Суть в том, что во многих случаях использования либо тип ссылки работает одинаково хорошо, но в том или ином типе это выгодно. Эффективность, упомянутая во многих ответах здесь, вероятно, очень мало заботит современные машины и файловые системы, если только вы не копируете файловую систему на микросхеме FLASH маленького встроенного контроллера. В функциональных различиях являются более важными, и , как правило , диктуют технические ограничения и окончательный выбор:
- Жесткая ссылка «источник» может быть безопасно перемещена, в то время как мягкая ссылка будет разорвана.
- Жесткая ссылка неотличима от файла, с которым она была связана, и файл жив, пока жива любая из жестких ссылок; мягкая связь асимметрична.
- Жестко связанный одноранговый узел выходит из связанной группы в случае удаления и повторного создания, но мягкая ссылка не теряет своей цели.
- Мягкая ссылка может пересекать файловые системы, жесткая ссылка не может.
- Мягкая ссылка может указывать на каталог, жесткая ссылка обычно не может (и практически всегда не должна).
Кроме того, я должен указать, что библиотечный вызов, который удаляет файл, вызывается unlink() по причине! Каждая запись в каталоге - это просто изначально жесткая ссылка на свой индекс.
Я читал в текстовых книгах, что Unix /Linux не разрешает жесткие ссылки на каталоги, но разрешает софт-ссылки. Это потому, что, когда у нас есть циклы, и если мы создаем жесткие ссылки, и через какое-то время мы удалим исходный файл, он укажет на некоторое значение мусора?
Если циклы были единственной причиной того, что не разрешали жесткие ссылки, то почему допустимы ссылки на каталоги?
Это просто плохая идея, так как нет никакой возможности рассказать разницу между жесткой ссылкой и оригинальным именем.
Разрешение жестких ссылок на каталоги приведет к поломке направленной структуры ациклического графа файловой системы, возможно, создавая циклы каталогов и подвешенные подкаталоги каталогов, что сделает ошибки fsck и любые другие ошибки, связанные с файловыми файлами.
Во-первых, чтобы понять это, давайте поговорим об инодах. Данные в файловой системе хранятся в блоках на диске, и эти блоки собираются вместе с помощью inode. Вы можете думать об inode как файле. Иноды не имеют имен файлов. Вот где ссылки входят.
Ссылка - это просто указатель на индексный дескриптор. Каталог - это индексный дескриптор, содержащий ссылки. Каждое имя файла в каталоге - это просто ссылка на индексный дескриптор. Открытие файла в Unix также создает ссылку, но это другой тип ссылки (это не именованная ссылка).
Жесткая ссылка - это просто дополнительная запись каталога, указывающая на этот индекс. Когда вы ls -l , число после разрешений - это именованный номер ссылки. У большинства обычных файлов будет одна ссылка. Создание новой жесткой ссылки на файл приведет к тому, что оба имени файла указывают на один и тот же индекс. Примечание:
Теперь вы можете ясно видеть, что нет такой вещи, как жесткая ссылка. Жесткая ссылка такая же, как и обычное имя. В приведенном выше примере test или test2 , который является исходным файлом и является жесткой ссылкой? К концу вы не можете сказать (даже по меткам времени), потому что оба имени указывают на одно и то же содержимое, тот же inode:
Флаг -i в ls показывает номера индексов в начале строки. Обратите внимание, что test и test2 имеют одинаковый номер inode, но test3 имеет другой.
Теперь, если вам разрешено делать это для каталогов, два разных каталога в разных точках файловой системы могут указывать на одно и то же. Фактически, субдир мог указать на его дедушку и бабушку, создав цикл.
Почему этот цикл вызывает беспокойство? Потому что, когда вы проходите, нет способа обнаружить, что вы зацикливаете (не отслеживая номера инодов при прохождении). Представьте, что вы пишете команду du , которая требует рекурсии через subdirs, чтобы узнать об использовании диска. Как du знает, когда он попадает в цикл? Это склонность к ошибкам и много учета, что du должен был бы сделать, просто чтобы снять эту простую задачу.
Символы - это совершенно другой зверь, поскольку они представляют собой особый тип «файла», к которому автоматически следуют многие API файловой системы. Обратите внимание: символическая ссылка может указывать на несуществующий пункт назначения, поскольку они указывают по имени, а не непосредственно в индексный дескриптор. Эта концепция не имеет смысла с жесткими ссылками, потому что простое существование «жесткой ссылки» означает, что файл существует.
Итак, почему du справляется с символическими ссылками легко и не сложно? Мы смогли увидеть выше, что жесткие ссылки неотличимы от обычных записей в каталоге. Символы, однако, являются специальными, обнаруживаемыми и пропускаемыми! du отмечает, что символическая ссылка является символической ссылкой и полностью ее пропускает!
За исключением точек монтирования, каждый каталог имеет один и только родительский: .. .
Один из способов сделать pwd - проверить устройство: inode для '.' а также '..'. Если они совпадают, вы достигли корня файловой системы. В противном случае найдите имя текущего каталога в родительском объекте, нажмите на него в стеке и начните сравнивать «../.». с «../..», затем «../../.» с помощью «../../..» и т. д. После того, как вы нажмете на корень, начните выскакивать и печатать имена из стека. Этот алгоритм основан на том, что каждый каталог имеет один и только один родитель.
Если жесткие ссылки на каталоги были разрешены, какой из нескольких родителей должен .. указать? Это одна из веских причин, почему жесткие ссылки на каталоги не разрешены.
Символы к каталогам не вызывают этой проблемы. Если программа хочет, она может сделать lstat() для каждой части пути и определить, когда встречается символическая ссылка. Алгоритм pwd возвращает истинный абсолютный путь для целевого каталога. Тот факт, что есть часть текста где-нибудь (символическая ссылка), указывающая на целевой каталог, практически не имеет значения. Существование такой символической ссылки не создает цикл на графике.
Вы можете использовать привязку привязки для имитации жестких каталогов ссылок
Мне нравится добавлять еще несколько вопросов по этому вопросу. Жесткие ссылки для каталогов разрешены в Linux, но ограниченным образом.
Один из способов проверить это - когда мы перечисляем содержимое каталога, мы находим два специальных каталога "." а также "..". Как мы знаем "." указывает на тот же каталог и «..» указывает на родительский каталог.
Итак, давайте создадим дерево каталогов, где «a» - это родительский каталог с каталогом «b» в качестве его дочернего элемента.
Запишите inode каталога "a". И когда мы делаем ls -la из каталога «a», мы можем видеть, что «.» каталог также указывает на тот же индекс.
И здесь мы можем обнаружить, что каталог «a» имеет три жесткие ссылки. Это связано с тем, что inode 797358 имеет три жестких контакта во имя «.». внутри «a» и имя «..» внутри каталога «b» и одно с именем «a» itslef.
Итак, здесь мы можем понять, что для справочников есть только ссылки для подключения к родительским и дочерним каталогам. И поэтому каталог без ребенка будет иметь только 2 жестких ссылки, поэтому каталог «b» будет иметь только две жесткие ссылки.
Одной из причин, по которым было отказано жесткое связывание каталогов, было бы исключить бесконечные циклы ссылок, которые будут путать программы, которые пересекают файловую систему.
Поскольку файловая система организована как дерево, и поскольку дерево не может иметь циклическую ссылку, этого следует избегать.
Ни одна из следующих причин не является реальной причиной отказа от жестких ссылок на каталоги; каждая проблема довольно легко решить:
- Циклы в древовидной структуре вызывают сложный обход
- несколько родителей, так что это «реальный»?
- сбор мусора файловой системы
реальная причина (как намекнул @ Thorbjørn Ravn Andersen) появляется, когда вы удаляете каталог с несколькими родителями из каталога, на который указывает .. :
Что теперь следует .. ?
Если каталог удален из родителя, но его количество ссылок еще больше чем 0 , тогда должно быть что-то, где-то еще указывая на это. Вы не можете оставить .. , указывая на ничего; многие программы полагаются на .. , поэтому системе придется пройти через весь файловой системы , пока не найдет первое, что указывает на удаленный , чтобы обновить .. . Либо это, либо файловая система должны содержать список всех каталогов, указывающих на жесткий связанный каталог.
В любом случае это будет накладные расходы и дополнительные осложнения для метаданных файловой системы и /или кода, поэтому дизайнеры решили не допускать этого.
Создание жестких ссылок в каталогах будет невозвратным. Предположим, что:
Я привязываю его к /dir2 .
Итак, /dir2 теперь также содержит все эти файлы и каталоги
Что, если я передумаю? Я не могу просто rmdir /dir2 (потому что он не пуст)
И если я рекурсивно удаляю в /dir2 . он также будет удален из /dir1 !
ИМХО это в значительной степени достаточная причина, чтобы этого избежать!
Это хорошее объяснение. Что касается «Какой из нескольких родителей должен указывать?» одним из решений было бы для процесса поддерживать полный путь wd, либо как inodes, либо как строку. inodes будут более надежными, поскольку имена могут быть изменены. По крайней мере, в прежние дни для каждого открытого файла был встроенный индексный индекс, который был увеличен при каждом открытии файла и уменьшался при закрытии. Когда он достигнет нуля, он и хранилище, на которое он указал, будут освобождены. Когда файл больше не открывается кем-либо, он (The-core copy) будет оставлен. Это поддержало бы путь как допустимый, если какой-либо другой процесс переместил каталог в другой каталог, в то время как подкаталог находился на пути другого процесса. Подобно тому, как вы можете удалить открытый файл, но он просто удален из каталога, но все же открыт для любых процессов, у которых есть его.
Каталоги с жесткой связью, которые были свободно разрешены в Bell Labs UNIX, по крайней мере, V6 и V7, не знают о Беркли или позже. Флаг не требуется. Не могли бы вы создать петли? Да, не делай этого. Очень ясно, что вы делаете, если делаете цикл. Пустота, если вы поправляете узлы, завязывающие вокруг шеи, пока вы ждали, когда ваша очередь будет прыгать с парашютом из самолета, если у вас есть другой конец, удобно висящий на крючке на объемной голове.
То, что I надеялось сделать с ним сегодня, состояло в том, чтобы жестко связать lhome с домом, чтобы я мог иметь /home /administ, независимо от того, был ли у меня /home закрыт автомат поверх дома, что automount имеет символическую ссылку с именем administ в /lhome /administ. Это позволяет мне иметь административную учетную запись, которая работает независимо от состояния моей основной домашней файловой системы. Этот IS эксперимент для linux, но я думаю, что однажды научил SunOS, основанный на UCB, что автомонтирование выполняется на уровне строки ascii. Трудно понять, как их можно было бы сделать иначе как слой поверх любого произвольного FS.
Я читал в других местах. и .. уже не файлы в каталоге. Я уверен, что для этого есть веские причины, и большая часть того, что нам нравится (например, возможность монтировать NTFS), возможно из-за таких вещей, но некоторые из элегантности UNIX были в реализации. Именно такие преимущества, как общность и податливость, обеспечили эту элегантность, которая позволила ей быть настолько прочной и устойчивой в течение четырех десятилетий. Поскольку мы теряем элегантные реализации, это в конечном итоге станет как Windows (я надеюсь, что я ошибаюсь!). Затем кто-то создаст новую ОС, основанную на элегантных принципах. Что-то думать о. Возможно, я ошибаюсь, я не (очевидно) знаком с текущей реализацией. Это является удивительным, хотя, насколько применимо 30-летнее понимание Linux . большую часть времени!
Я читаю это введение в командную строку от Марка Бейтса.
В первой главе он упоминает, что жесткие ссылки не могут охватывать файловые системы.
Важно отметить, что жесткие ссылки - это то, что они работают только с текущей файловой системой. Вы не можете создать жесткую ссылку на файл в другой файловой системе. Для этого вам нужно использовать символические ссылки, раздел 1.4.3.
Я знаю только одну файловую систему. Первый, начиная с root ( / ). Это утверждение, что жесткие ссылки не могут охватывать файловые системы, не имеет для меня смысла.
Статья в Wikipedia в файловых системах Unix также не полезна.
4 ответа
Надеюсь, я смогу ответить на этот вопрос таким образом, который имеет смысл для вас. Файловая система в Linux, как правило, состоит из раздела, который отформатирован одним из разных способов (должен любить выбор!), На котором хранятся ваши файлы. Будь то ваши системные файлы или ваши личные файлы . все они хранятся в файловой системе. Эта часть, которую вы, кажется, понимаете.
Но что, если вы разделите свой жесткий диск на несколько разделов (подумайте, что Apple Pie разрезан на куски) или добавьте дополнительный жесткий диск (возможно, USB-накопитель?). Для аргументации все они также имеют файловые системы.
Когда вы смотрите на файлы на своем компьютере, вы видите визуальное представление данных в файловой системе вашего раздела. Каждое имя файла соответствует тому, что называется inode, где ваши данные, за кулисами, действительно живут. Жесткая ссылка позволяет вам иметь несколько «имен файлов» (из-за отсутствия лучшего описания), которые указывают на один и тот же индекс. Это работает только в том случае, если эти жесткие ссылки находятся в одной файловой системе. Символическая ссылка вместо этого указывает на «имя файла», которое затем связано с inode, хранящим ваши данные. Простите мое грубое произведение, но, надеюсь, это объясняет лучше.
здесь, image.jpg и image2.jpg оба указывают прямо на ваши данные. Они оба являются жесткими ссылками. Однако .
В этом (грубом) примере изображение2.jpg не указывает на ваши данные, оно указывает на image.jpg . что является ссылкой на ваши данные.
Символьные ссылки могут работать через границы файловой системы (при условии, что файловая система подключена и смонтирована, например, ваша USB-флешка). Однако жесткая ссылка не может. Он ничего не знает о том, что находится в вашей другой файловой системе или где хранятся ваши данные.
Надеюсь, это поможет лучше понять.
Файловая система состоит из структуры каталога, составленной для записей каталога для организации файлов. Каждая запись в каталоге связывает имя файла с inode .
Софт-ссылки ( символический ) - это записи в каталоге, которые не содержат данных, она просто указывает на другую запись (файл или каталог в той же файловой системе или другом файле система). И когда вы удаляете указанный файл, символическая ссылка становится непригодной.
Жесткие ссылки - это запись в каталоге, содержащая имя файла и inode . Когда вы удаляете последнюю жесткую ссылку, вы больше не можете обращаться к файлу.
Вывод:
Поскольку inode - это структура данных, используемая для представления объект файловой системы, он является внутренним для файловой системы, и вы не можете указать inode другой файловой системы.
Таким образом, жесткие ссылки действительны только в одной файловой системе, но софт-ссылки (символическая ссылка) могут охватывать файловые системы , поскольку они просто указывают на другую запись в каталоге (интерфейс файла -система, а не внутренний объект).
Корневая файловая система может состоять из нескольких файловых систем; /usr/local может быть смонтирован на отдельном разделе и /home может быть в другом разделе на сетевом диске где-то в другом месте. В этом случае жесткая ссылка для /usr/local/bin/git (например) может не создаваться вне /usr/local , , потому что он будет охватывать файловые системы .
Причиной этого является то, что иноды выделяются отдельно для / , /usr/local и /home (опять же в этом примере), и когда вы создаете жесткую ссылку, вы действительно просто введите дополнительное имя для inode.
Жесткие ссылки приводят к сохранению их цели. Пока существует какая-либо жесткая ссылка, система гарантирует, что ее цель не может быть освобождена. Поэтому необходимо, чтобы все носители, которые могли содержать жесткие ссылки на конкретный индексный дескриптор, монтировались в любое время, когда система пыталась определить, существуют ли какие-либо ссылки.
Учитывая, что время жизни inode обычно определяется путем сохранения отсчетов ссылок, а не для сканирования ссылок, может быть возможно организовать вещи для того, чтобы две или более файловые системы, которые содержали ссылки друг на друга, могли использоваться независимо, если не было необходимости которые соединяются между системами, и при условии, что нет необходимости использовать fsck на одном из них. Однако, если inode подсчитывает одну из систем, которые были нарушены, единственный способ сделать эту систему полезной снова - использовать форму fsck-операции, которая могла бы сканировать обе файловые системы для ссылок. Из-за этого ограничения, хотя возможно, что можно разрешить использование двух взаимосвязанных файловых систем независимо друг от друга, преимущества этого будут, вероятно, слишком ограниченными, чтобы сделать это полезным.
A жесткая ссылка определяется как указатель на индексный дескриптор. софт-ссылка , также известная как символическая ссылка , определяется как независимый файл, указывающий на другую ссылку без ограничений жестких ссылок.
В чем разница между файлом и жесткой ссылкой? Жесткая ссылка указывает на индексный дескриптор, так что это файл? Сама запись inode? Или inode с жесткой ссылкой?
Предположим, я создаю файл с прикосновением. Затем запись inode создается в таблице inode . И я создаю жесткую ссылку, которая имеет тот же номер inode, что и файл. Так я создал новый файл? Или это файл, который определен как индекс?
Самый короткий ответ:
- Файл представляет собой анонимный блок данных
- жесткая ссылка - это имя файла
- символическая ссылка - это специальный файл, содержимое которого является именем пути
Unix-файлы и каталоги работают точно как файлы и каталоги в реальном мире (и not , как папки в реальном мире); Файловые системы Unix (концептуально) структурированы следующим образом:
- файл является анонимным блоком данных; он не имеет имени, только номер (inode)
- каталог - это особый вид файла, который содержит сопоставление имен с файлами (более конкретно, inodes); поскольку каталог - это всего лишь файл, каталоги могут иметь записи для каталогов, так как рекурсия реализована (обратите внимание, что при вводе файловых систем Unix это было not , очевидно, много операционных систем, t позволяет каталогам содержать каталоги тогда)
- эти записи в каталоге называются hardlinks
- символическая ссылка - это еще один особый вид файла, содержимое которого является именем пути; это имя пути интерпретируется как имя другого файла
- Другие типы специальных файлов: сокеты, фиксы, блокирующие устройства, символьные устройства.
Помня об этой метафоре и особенно учитывая, что каталоги Unix работают как каталоги реального мира, а not , такие как папки реального мира, объясняют многие «странности», с которыми часто сталкиваются новички, например : почему я могу удалить файл, на который у меня нет доступа для записи? Ну, например, вы не удаляете файл, вы удаляете одно из многих возможных имен для файла, и для этого вам нужен только доступ на запись к каталогу, а не к файлу. Также как в реальном мире.
Или, почему я могу оборвать символические ссылки? Ну, симлинк просто содержит путь. Ничто не говорит о том, что на самом деле должен быть файл с таким именем.
Мой вопрос в том, какая разница между файлом и жесткой ссылкой?
Разница между файлом и жесткой ссылкой совпадает с разницей между вами и строкой с вашим именем в телефонной книге.
Жесткая ссылка указывает на индексный дескриптор, поэтому какой файл? Inode-запись сама? Или Inode с жесткой ссылкой?
Файл представляет собой анонимную часть данных. Вот и все. Файл не является inode, файл имеет inode, так же, как вы не номер социального страхования, вы имеете SSN.
Жесткая ссылка - это имя файла. Файл может иметь много имен.
Предположим, я создаю файл с прикосновением, затем запись Inode создается в таблице Inode .
И я создаю жесткую ссылку, которая имеет тот же номер Inode с файлом.
Нет. Жесткая ссылка не имеет номера inode, так как это не файл. Только файлы имеют номера inode.
Жесткая ссылка связывает имя с номером inode.
Или файл просто определяется как Inode?
Нет. Файл имеет индексный дескриптор, он не является inode.
Жесткая ссылка - это запись в каталоге. Файл может иметь несколько записей каталога, если он присутствует под разными именами или в разных каталогах. Запись в каталоге называется «жесткой ссылкой», когда она связана с другими записями каталога для одного и того же файла.
Индед содержит метаданные файла, отличные от его имени и содержимого (расположение содержимого, разрешений, временных меток и т. д.). В файле есть один индекс. (Не все файловые системы помещают метаданные в четко идентифицируемое пространство на диске, которое вы могли бы назвать «inode», но это общая архитектура.) Запись в каталоге связывает имя с inode. Возможно, что более чем одна запись в каталоге ссылается на один и тот же индекс, следовательно, термин «ссылка». Такая ссылка называется «жесткой ссылкой» против оппозиции «мягким ссылкам» или «символическим ссылкам», которые не говорят «для этого имени, используйте этот индекс», но «для этого имени, посмотрите на другое имя».
Думайте о файлах как о комнатах и каталогах как о дверях. «Открыть файл /foo/bar " означает "перейти в коридор /foo и перейдите в комнату bar ". «Идите в комнату bar " действительно означает "откройте дверь с надписью bar и войдите в комнату ", но" перейдите в комнату bar "- это незаметный способ сказать то же самое в более короткий путь. Возможно иметь более одной двери, ведущей в ту же комнату.
Когда вы создаете жесткую ссылку на существующий файл ( ln existing new ), вы создаете вторую ссылку на тот же файл, т.е. вы создаете новую запись каталога, которая ссылается на уже существующий файл. После создания две записи в каталоге имеют одинаковый статус: нет «первичного», а второго - «вторичного», это только обе ссылки на один и тот же файл.
Вы также можете удалить все ссылки на файл без удаления самого файла. Это происходит, если вы удаляете файл (т. Е. Удаляете все его записи в каталоге), в то время как у программы все еще есть файл. Файл остается в файловой системе, он фактически удаляется только тогда, когда последний процесс, который открыл файл, закрывает его. В метафоре «номер-дверь» комната, в которой нет дверей, все еще занимает место.
В дополнение ко всем другим ответам я хочу указать следующие важные свойства:
Программная ссылка является подлинной ссылкой, т. е. это небольшой файл, содержащий имя пути. Решение программной ссылки прозрачно для приложения: если процесс открывает файл, скажите /this/path/here , который является символической ссылкой, указывающей на /that/other/path , тогда вся обработка открытия /that/other/path выполняется ОС , Кроме того, если /that/other/path оказывается самой символической ссылкой, то это также касается ОС. Фактически, ОС следует цепочке символических ссылок, пока не найдет что-то еще (например, обычный файл) или пока не достигнет SYMLOOP_MAX (см. ---- +: = 5 =: + ----) много записей, и в этом случае ОС (точнее: соответствующий системный вызов) возвращает ошибку и устанавливает sysconf(3) до errno . Таким образом, круговая ссылка, такая как ELOOP , не остановит процесс. (Для систем Linux см. xyz -> xyz для получения полной информации.)
Обратите внимание, что процесс может проверить, является ли имя пути символической ссылкой или нет с помощью path_resolution(7) и может изменять его файловые атрибуты ( хранится в таблице inode) через lstat(2) и другие (см. lchown(2) для всей истории.)
Теперь, с точки зрения разрешения, вы заметите, что символические ссылки всегда имеют разрешения 777 ( symlink(7) в символической нотации). Это связано с тем, что любые другие разрешения можно обойти, обратившись к фактическому файлу. И наоборот, 777 для символической ссылки не делает доступным символический файл, если он не был доступен в первую очередь. Например, символическая ссылка с разрешениями 777, указывающая на файл с разрешениями 640, делает файл недоступным для «другого» (для широкой публики). Другими словами, файл rwxrwxrwx доступен через символическую ссылку тогда и только тогда, когда он доступен напрямую, т. Е. Без косвенности. Таким образом, разрешения symlink не имеют никакого эффекта безопасности.
Одна из основных видимых различий между hardlinks и symlinks (программные ссылки a.k.a.) заключается в том, что символические ссылки работают через файловые системы, а жесткие ссылки ограничены одной файловой системой. То есть, файл в разделе A может быть привязан к символу из раздела B, но он не может быть жестко привязан оттуда. Это ясно из того факта, что hardlink - это фактически запись в каталоге, которая состоит из имени файла и номера inode, а номера индексов уникальны только для файловой системы.
Термин hardlink на самом деле несколько вводит в заблуждение. Хотя для символических ссылок источник и адресат четко различимы (символическая ссылка имеет свою собственную запись в таблице inode), это неверно для жестких ссылок. Если вы создаете жесткую ссылку для файла, исходная запись и жесткая ссылка неразличимы с точки зрения того, что было первым. (Так как они относятся к одному и тому же inode, они делятся своими файловыми атрибутами, такими как владелец, разрешения, временные метки и т. Д.). Это приводит к утверждению, что каждая запись в каталоге на самом деле является жесткой линией, а жесткая привязка файла означает только создание второй ( или третья, или четвертая . ) жесткая ссылка. Фактически, каждый индексный индекс хранит счетчик количества жестких ссылок на этот индекс.
Наконец, обратите внимание на то, что обычные пользователи могут не каталогизировать ссылки. Это связано с тем, что это необходимо сделать с предельной осторожностью: неосторожный пользователь может вводить циклы в строго иерархическое дерево файлов, в котором все обычные инструменты (например, xyz ), и сама ОС не готова к работе.
В первой главе он упоминает, что жесткие ссылки не могут охватывать файловые системы.
В отношении жестких ссылок важно отметить, что они работают только в текущей файловой системе. Вы не можете создать жесткую ссылку на файл в другой файловой системе. Для этого вам нужно использовать символические ссылки, раздел 1.4.3.
Я знаю только одну файловую систему. Тот, который начинается с root ( / ). Это утверждение, что жесткие ссылки не могут охватывать файловые системы, не имеет смысла для меня.
Надеюсь, я смогу ответить на это так, чтобы это имело смысл для вас. Файловая система в Linux, как правило, состоит из раздела, который отформатирован одним из различных способов (должен любить!), В котором вы храните свои файлы. Будь то ваши системные файлы или ваши личные файлы . все они хранятся в файловой системе. Эту часть вы, похоже, поняли.
Но что делать, если вы разбили свой жесткий диск на несколько разделов (например, Apple Pie разрезать на части) или добавили дополнительный жесткий диск (возможно, USB-накопитель?). Ради аргумента, у них всех также есть файловые системы.
Когда вы смотрите на файлы на вашем компьютере, вы видите визуальное представление данных в файловой системе вашего раздела. Каждое имя файла соответствует тому, что называется инодом, и именно там ваши данные за кулисами действительно живут. Жесткая ссылка позволяет вам иметь несколько «имен файлов» (из-за отсутствия лучшего описания), которые указывают на один и тот же индекс. Это работает, только если эти жесткие ссылки находятся в одной файловой системе. Вместо этого символическая ссылка указывает на «имя файла», которое затем связывается с индексом, содержащим ваши данные. Простите мою грубую работу, но, надеюсь, это объясняет лучше.
Здесь, image.jpg и image2.jpg указывают непосредственно на ваши данные. Они оба жесткие ссылки. Тем не мение.
В этом (сыром) примере image2.jpg не указывает на ваши данные, он указывает на image.jpg . который является ссылкой на ваши данные.
Символические ссылки могут работать через границы файловой системы (при условии, что файловая система подключена и смонтирована, как ваша флешка). Однако жесткая ссылка не может. Он ничего не знает о том, что находится в вашей другой файловой системе или где хранятся ваши данные.
Читайте также: