Почему жесткие ссылки существуют?
Я думал, что просто упомяну о byobu обертка, которая доступна для экрана, который делает ее настолько лучшим правом из поля. Я не знаю, доступно ли что-то вроде этого для tmux, но byobu сделанный моим .screenrc только горстка строк. Проверьте эту быструю статью о byobu и снимки экрана. Страница проекта для byobu описывает имя, происходящее из японского термина для декоративного, экраны мультипанели, которые служат складными межкомнатными перегородками. Кроме того, просто выполнение его не вредит Вашим экранным настройкам, таким образом, можно безопасно попробовать его. После того как Вы запускаете сессию с byobu можно свободно повторно подключить к нему использование screen и все еще не освободите настройки, сделанные byobu (так используйте его только для начального вызова). Два основных преимущества его:
- Запускает экран с нескольких строк состояния с полезной информацией
- Предоставляет много привязок клавиш легче функциональности экрана доступа
Я не использую часть привязок клавиш, но определенно нахожу строки состояния полезными.
Также Вы могли бы найти Экран По сравнению со ссылкой tmux полезным. Я думаю, что большая часть из него уже упоминается существующими ответами.
Основное преимущество жестких ссылок состоит в том, что по сравнению с гибкими ссылками нет никакого штрафа размера или скорости. Гибкие ссылки являются дополнительным слоем косвенности сверх нормального доступа к файлу; ядро должно разыменовать ссылку, когда Вы открываете файл, и это занимает небольшое количество времени. Ссылка также берет небольшое количество пространства на диске, для содержания текста ссылки. Эти штрафы не существуют с жесткими ссылками, потому что они встроены в самую структуру файловой системы.
Лучшим способом я знаю о видеть, что это:
$ ls -id .
1069765 ./
$ mkdir tmp ; cd tmp
$ ls -id ..
1069765 ../
-i опция к ls заставляет его дать Вам inode количество файла. В системе, где я подготовил пример выше, я, оказалось, был в каталоге с inode номером 1069765, но определенное значение не имеет значения. Это - просто уникальное значение, которое определяет конкретный файл/каталог.
То, что это говорит, то, что, когда мы входим в подкаталог и смотрим на другую названную запись файловой системы .., это имеет то же inode число, которое мы получили прежде. Этого не происходит, потому что оболочка интерпретирует .. для Вас, как это происходит с MS-DOS и Windows. В файловых системах Unix .. реальная запись каталога; это - указание жесткой ссылки назад на предыдущий каталог.
Жесткие ссылки являются сухожилиями, которые связывают каталоги файловой системы. Когда-то давно Unix не имел жестких ссылок. Они были добавлены для превращения исходной плоской файловой системы Unix в иерархическую файловую систему.
(Для больше на этом, посмотрите, Почему делает '/', имеют '..' запись?.)
Также несколько распространено в системах Unix для нескольких различных команд быть реализованным тем же исполняемым файлом. Это, кажется, больше не имеет место на Linux, но в системах я использовал в прошлом cp, mv и rm были всеми одинаковыми исполняемый файл. Это имеет смысл, если Вы думаете об этом: при перемещении файла между объемами это - эффективно копия, сопровождаемая удалением, таким образом, mv уже должен был реализовать функции других двух команд. Исполняемый файл может выяснить, какую операцию обеспечить, потому что это передается имя, которым это назвали.
Другим примером, распространенным во встроенных Linux, является BusyBox, единственный исполняемый файл, который реализует десятки команд.
Я должен указать, что в большинстве файловых систем, пользователям не разрешают сделать жесткие ссылки на каталоги. . и .. записи автоматически организованы кодом файловой системы, который обычно является частью ядра. Ограничение существует, потому что возможно вызвать серьезные проблемы файловой системы, если Вы не осторожны с тем, как Вы создаете и используете жесткие ссылки каталога. Это - одна из многих причин, гибкие ссылки существуют; они не несут тот же риск.
-
1О "Ссылке также берет небольшое количество пространства на диске, для содержания текста ссылки". В современных файловых системах никакое дополнительное пространство не используется для хранения пути ссылок, как сама запись каталога используется для хранения его, по крайней мере, если имя не является слишком длинным для установки. Это называют "быстрыми символьными ссылками" – jlliagre 25.11.2013, 23:02
-
2, я добавил бы, что некоторые приложения не знают, как обработать мягкий (sym) ссылки, и таким образом жесткие ссылки могут быть полезными для предотвращения дублирований при конфигурировании их путем ссылки к тем же данным/файлам конфигурации. Примером является ioquake3, который не может следовать за файлами symlinked pk3, но может следовать за файлами hardlinked pk3. – gaborous 16.12.2014, 14:56
-
3Кроме того, при удалении цели символьной ссылки файла не стало, и символьная ссылка повреждается. Проблема, которая не существует с жесткой ссылкой. – spectras 19.06.2016, 01:31
Одно использование hardlinks, который чрезвычайно полезен, находится в возрастающих резервных копиях, объединенных с rsync. Это сохраняет партию пространства и делает процедуру восстановления действительно легкой. Я использую тот подход для резервного копирования в моих серверах.
Не торопитесь для чтения этого объяснения.
Если после того, чтобы читать, что страница Википедии Ваш вопрос, "почему был бы, я когда-нибудь использую их", затем Вы не понимаете, каковы жесткие ссылки.
Ссылка является записью каталога, которая указывает на блоки на диске. Другими словами, каждый файл в Вашей системе имеет по крайней мере одну ссылку. Когда Вы rm файл фактический системный вызов unlink(). Это удаляет запись каталога. Блоки на диске не изменились, но ссылки не стало, таким образом файла не стало из списка каталогов.
Вы лично никогда не можете использовать жесткие ссылки, но они на всем протяжении Вашей системы. Например:
$ ls -li /bin | grep 53119771
53119771 -rwxr-xr-x 3 root root 26292 2010-08-18 10:15 bunzip2
53119771 -rwxr-xr-x 3 root root 26292 2010-08-18 10:15 bzcat
53119771 -rwxr-xr-x 3 root root 26292 2010-08-18 10:15 bzip2
Вы видите это bunzip2, bzcat и bzip все использование тот же inode. В сущности это - один файл с тремя именами. У Вас могло быть три копии файла, но почему? Это только израсходовало бы дисковое пространство излишне.
-
1Но существует также много символьных ссылок в
/bin, Я предполагаю, что это - один из источников беспорядка. Почему иногда исполняемые файлы были бы symlinked и иногда - hardlinked? – Dmitry Pashkevich 01.03.2013, 17:39 -
2Этому ответу не удается обеспечить любую причину вообще использования жестких ссылок по гибким ссылкам. – Mark Amery 12.05.2015, 21:30
Существует любое количество использования. Я использую их для создания основанных на файле блокировок. Ссылка (2) системный вызов является атомарной, в отличие от большинства других системных вызовов.
Другое использование в rsnapshot, где резервные копии берутся со временем с помощью жестких ссылок для сокращения количества дискового пространства. Если файл не изменился, то файл трудно связан с более старыми экземплярами файла, файлы, которые изменились, копируются снова.
Я также использую их для выгрузки файлов конфигурации на серверах: rm file.cfg && ln ~/tmp/file.cfg file.cfg, затем ~/tmp /* файлы может быть удален безопасно.
Для добавления к нескольким хорошим обсуждениям уже представляют...
- Путем доступ ресурса для программ реализован в Unix (т.е. "все - файл"), средства, что инфраструктура для обработки нескольких ссылок на файл требуется, чтобы ОС работала вообще, таким образом, здесь нет никакой добавленной стоимости.
- Путем каталоги были реализованы в исходных файловых системах Unix (т.е. список фиксированного формата
(inode, name)пары означают, что нет никаких дополнительных расходов на в файловой системе к наличию hardlinks (хорошо, пока мы предотвращаем циклы путем запрещения hardlinke к каталогам (кроме.и..(это начинает чувствовать себя подобно шепелявости кому-либо еще?)))
таким образом, мы получаем их бесплатно.
Вероятно, мне следует рассказать о ловушке сценария с жесткими ссылками. Жесткая ссылка будет просто тем же файлом с другим именем и/или другим местоположением , пока существует исходный связанный файл . Неправильно даже думать о файле как об "оригинальном" :, оба являются элементами каталога сами по себе, и оба (или более )являются равноправными узлами. Для долгоживущих -файлов это может быть благом, но если один из пары будет удален, а затем создан, даже с тем же именем и содержимым, файлы разделятся.
Предположим, вы создали жесткую ссылку /foo/myfileна /repo/myfile. Оба являются указателями на одни и те же данные файла; меняешь одно, меняется другое. Но предположим, что /repoсодержит репозиторий Git. Если вы извлекаете ветку, в которой нет myfile, /repo/myfileудаляется. В этот момент /foo/myfileстановится простой копией /repo/myfile, как в тот момент, когда другой из пары был несвязан. Легко даже не заметить, когда вы переключаетесь между ветвями, что репертуар файлов меняется, но когда вы извлекаете исходную ветвь, Git создает новый файл /repo/myfile. Если бы вы не обращали внимания, вы бы удивились, почему эти два файла теперь имеют разное содержимое, хотя это легко понять, так как отношения жесткой связи между файлами не имеют понятия об их именах. Мягкая ссылка,напротив, выжил бы в этом цикле удаления -создания.
С другой стороны, программное обеспечение, использующее жесткие ссылки, прекрасно понимает это, и Git — яркий тому пример. Git почти бесплатно клонирует репозиторий в той же файловой системе, поскольку по умолчанию использует жесткие ссылки вместо копирования файлов. Для Git жесткая ссылка является идеальным вариантом использования, потому что его объектные и пакетные файлы никогда не меняются, поэтому один клон репозитория никогда не изменит другой (. Git знает, что нельзя жестко -связывать изменяемые файлы ), любой из клонов может быть удален без каких-либо предосторожностей :нет необходимости отслеживать, какой из них является "оригиналом" и на самом деле содержат файлы :любая из жестких ссылок является равноправным партнером и " содержит" полный файл. Мягкие ссылки просто не будут работать здесь.
Другое преимущество жесткой ссылки заключается в том, что любую ссылку можно переместить, не нарушая доступа к содержимому файла. При использовании программных ссылок перемещение исходного файла делает все программные ссылки на него повисшими.
Суть в том, что во многих случаях любой тип ссылки работает одинаково хорошо, но в некоторых случаях преимущество имеет тот или иной тип. Эффективность, упомянутая во многих ответах здесь, вероятно, мало волнует современные машины и файловые системы, если только вы не очищаете файловую систему на микросхеме FLASH маленького встроенного контроллера. функциональные различия более важны и обычно диктуют технические ограничения и окончательный выбор :
.- Жесткая ссылка «источник» может быть безопасно перемещена, в то время как программная ссылка сломается.
- Жесткая ссылка неотличима от файла, из которого она была связана, и файл активен до тех пор, пока активна любая из жестких ссылок; мягкая ссылка асимметрична.
- Жестко -связанный одноранговый узел выходит из связанной группы, если он удаляется и -создается повторно, но мягкая ссылка не теряет своей цели.
- Мягкая ссылка может пересекать файловые системы, а жесткая ссылка — нет.
- Мягкая ссылка может указывать на каталог, жесткая ссылка обычно не может (и практически всегда не должна ).
Кроме того, я должен отметить, что библиотечный вызов, который удаляет файл, называется unlink()не просто так! Каждая запись каталога — это всего лишь изначально единственная жесткая ссылка на свой индексный дескриптор.