Простое объяснение хардлинков и симлинков | автор: Luca | 26 июля 2010
Категория: GNU/Linux
Предлагаю статью в которой автор простыми и понятными словами объясняет чем символический ссылки отличаются от жеских ссылок. Материал рассчитан на новичков в системе linux.
Символические ссылки
Чтобы понять, что такое символические ссылки – представьте себе каталог бумажной документации (куча полок с документами). Пусть есть полки «Строительные стандарты» и «Машиностроительные стандарты». Но как поступить, если у нас есть стандарт, относящийся к проектированию механосборочных цехов? Ведь этот стандарт может понадобиться и строителям и в машиностроении.
Первый подход состоит в том, чтобы положить этот документ в секцию «Строительные», а в секции «Машиностроение» оставить заметку, что документ с таким названием находится в секции «Строительные стандарты». Такой подход применим, если документ более относится к строительной тематике, нежели к машиностроению.
Это и называется «символическая ссылка» – файл помещается в каталог («Строительные»), а в другом каталоге («Машиностроение») создается специальный файл, указывающий на документ в каталоге «Строительные». При попытке прочитать или редактировать файл-ссылку, файловая система перенаправит нас на файл-оригинал. При удалении символической ссылки – исходный файл остается. Т.е. всё как в приведенной выше аналогии с полками. Если удалить исходный документ – ссылка останется на месте.
Недостаток такого подхода в том, что при перемещении исходного файла, ссылка не изменит автоматически путь на новый. Еще недостаток – не всегда можно определить, в какой каталог (на какую полку) положить исходный файл – иногда файл может относиться одинаково ко двум или даже трем категориям. От этих недостатков свободны жесткие ссылки.
Практическая работа по символическим ссылкам:
Найдите легкий способ создания символических ссылок в вашей любимой оконной среде (например, с помощью drag-n-drop); создайте символические ссылки на рабочем столе для наиболее часто используемых приложений.
Жесткие ссылки
Жесткие ссылки чем-то похожи на библиотечную систему карточек – когда для каждой книги есть свой уникальный идентификатор, и зная его – мы можем попросить библиотекаря дать нам эту книгу. При чем названия разных книг могут совпадать, но идентификаторы – никогда (это важный момент, обратите внимание).
Представим, что есть книга, пусть «О мышах и людях». В нашем городе подобные вещи не пользуются особой популярностью, так что предположим что эта книга есть только в одной, скажем, в центральной библиотеке. Но вот мы пришли в местную библиотеку и не нашли там этой книги. Зато там есть карточка, в которой указан код книги. И вот, библиотекарь звонит в другие библиотеки и узнает, что такая книга есть в центральной. Скажем, у нас хороший сервис и вам тут же ее привозят. Вот так работают жесткие ссылки.
Чтобы представление о жестких ссылках было полное, сделаем кое-какие уточнения. В местной библиотеке могут убрать карточку этой книги (скажем, библиотека была государственная, а стала частной). Но книга останется. Если же карточки на эту книгу уберут из всех библиотек – это может означать только одно – самой книги тоже нет (возможно кто-то взял последний экземпляр и не вернул, негодяй такой; помню, я долго не мог взять почитать в институтской библиотеке фантастический роман – его долго не отдавала какая-то девушка. С девушкой я так и не познакомился, но к счастью в файловой системе ваши «книги» всегда будут на месте, лишь бы вы не удалили последнюю «карточку» на нее – об этом ниже).
Рассмотрим теперь, как эта модель функционирует в файловой системе. На самом деле, всегда существует как минимум одна жесткая ссылка на файл. Т.е. сам файл (его содержимое) находится где-то на жестком диске, и у него есть уникальный номер (как книга в Хранилище в модели выше). А имя файла хранится отдельно, в «файловом индексе» (inode) – он соответствует карточке в модели выше. Также в файловом индексе содержится тот же уникальный номер – а поскольку номера одинаковы, то этот файловый индекс и будет являться жесткой ссылкой на само содержимое файла.
Как видим, файловый индекс соответствует карточке, а содержимое – книге. И хранятся они так же раздельно, в разных областях жесткого диска – (карточки – в картотеке, книги – в хранилище). И таким же образом, как в примере с библиотеками, у одного файла может быть несколько имен («карточек» или «файловых индексов») – и столько же жестких ссылок с этими именами.
Если удалить оба файловых индекса (т.е. обе жестких ссылки) – то счетчик жестких ссылок для содержимого файла станет 0, и содержимое файла удалится. Когда говорят «удалить файл» – на самом деле это означает, что есть один файловый индекс, жестко связанный (по уникальному номеру) с содержимым этого файла – и удаляя этот (единственный) файловый индекс – содержимое файла стирается с жесткого диска автоматически.
Практическая работа по жестким ссылкам:
Выводы
- Символические ссылки удобно использовать, когда файл-оригинал будет находится по неизменному пути (не будет переноситься в дальнейшем) и его имя будет оставаться также неизменным. Нормально будет сделать символическую ссылку для запуска приложения /usr/bin/local/myapp из каталога рабочего стола, скажем /home/joe/Desktop. Таким образом из графической оболочки (например, KDE) можно будет быстро, одним щелчком мыши, запустить приложение myapp. Такая ссылка будет скорее всего всегда актуальная, т.к. в /usr/bin редко что переименовывается. Также немаловажно, что при обновлении программы myapp (скажем, ее удалят и на ее место скопируют новую копию) – ссылка останется актуальной. Наиболее часто я использую символические ссылки именно в таком ключе – создаю ссылки для приложений на рабочий стол
- Жесткие ссылки удобно использовать при другого рода динамике системы. Например, мы администрируем сервер электронной библиотеки. Есть книга, относящаяся к математике и музыке (назовем ее «Математика и музыка»). При чем оговоримся, что эта книга никогда не будет заменена на более новую с таким же именем файла. Вполне резонно будет сделать жесткие ссылки так, чтобы книга находилась и в разделе «Математика», и в разделе «Музыка»
- Чаще применяют символические ссылки; это связано с динамикой изменения системы. Например, при обновлениях старые файлы удаляются, создаются новые, с теми же именами, и жесткие ссылки не обеспечат правильного поведения
Примеры применения ссылок
- есть разные оболочки (интерпретаторы команд консоли) – bash, dash и т.д. Но всегда есть файл /bin/sh – это как раз символическая ссылка на конкретную программу (выполните команду «file /bin/sh», чтобы убедится в этом). Чтобы изменить реализацию интерпретатора команд в системе – достаточно изменить символическую ссылку sh на соответствующий исполняемый файл
- когда вы выполняете команду «ls -la» и видите каталоги «..» и «.» — это жесткие ссылки, создаваемые системой для предыдущего и текущего каталога соответственно. Сами вы не можете создавать жесткие ссылки на каталоги, а вот система может
- допустим, у вас есть фильм «Into the wild» и саундтреки (OST) к нему. Очевидно, саундтреки относятся и к данному фильму, и к категории «Музыка». Мы хотим видеть эти саундтреки и в каталоге фильма, и в каталоге музыки. Но если положить саундтреки и туда, и туда — это займет в 2 раза больше места на диске, и если вы захотите дополнить или изменить файлы саундтреков — придется делать это в двух местах. Выход из этой ситуации — положить саундтреки в каталог «Музыка» (очевидно, что к этой категории они относятся больше, чем к фильмам) и сделать на весь каталог саундтреков символическую ссылку, которая будет находиться в каталоге с фильмом:
~/Data/Video/Movies/Into the wild/OST -> ~/Data/Music/OST/Into the wild
- также есть замечательный инструмент, к ссылкам отношения не имеющий, но похожий по своей работе: «mount -o bind». Я применял эту команду для выкладывания на свой ftp-сервер музыки, фильмов и т.д. (чтобы выложить файлы на ftp-сервер, необходимо было поместить их в папку /home/ftp/pub, что и делала эта команда без необходимости копировать данные)
источник
Прочитано 5653 раз и оставлено 146 комментариев.
Предлагаю статью в которой автор простыми и понятными словами объясняет чем символический ссылки отличаются от жеских ссылок. Материал рассчитан на новичков в системе linux.
Символические ссылки
Чтобы понять, что такое символические ссылки – представьте себе каталог бумажной документации (куча полок с документами). Пусть есть полки «Строительные стандарты» и «Машиностроительные стандарты». Но как поступить, если у нас есть стандарт, относящийся к проектированию механосборочных цехов? Ведь этот стандарт может понадобиться и строителям и в машиностроении.
Первый подход состоит в том, чтобы положить этот документ в секцию «Строительные», а в секции «Машиностроение» оставить заметку, что документ с таким названием находится в секции «Строительные стандарты». Такой подход применим, если документ более относится к строительной тематике, нежели к машиностроению.
Это и называется «символическая ссылка» – файл помещается в каталог («Строительные»), а в другом каталоге («Машиностроение») создается специальный файл, указывающий на документ в каталоге «Строительные». При попытке прочитать или редактировать файл-ссылку, файловая система перенаправит нас на файл-оригинал. При удалении символической ссылки – исходный файл остается. Т.е. всё как в приведенной выше аналогии с полками. Если удалить исходный документ – ссылка останется на месте.
Недостаток такого подхода в том, что при перемещении исходного файла, ссылка не изменит автоматически путь на новый. Еще недостаток – не всегда можно определить, в какой каталог (на какую полку) положить исходный файл – иногда файл может относиться одинаково ко двум или даже трем категориям. От этих недостатков свободны жесткие ссылки.
Практическая работа по символическим ссылкам:
Цитата:В качестве самостоятельного упражнения – попробуйте создать символическую ссылку на каталог.
cd # в домашний каталог
mkdir -p standards/{civil,mechanical} # создать структуру необходимых каталогов
cd standards/civil # в каталог строительных стандартов
touch document1.txt # создаем новый файл со стандартом
echo "some text" > document1.txt # содержимое...
man ln # для выхода нажать "q"; это справка по "ln", почитайте
cd ../mechanical/ # в каталог машиностроительных стандартов
ln -s ../civil/document1.txt document1.txt # создаем симв. ссылку
# с таким же именем
ls -l # посмотрим, что вышло
pwd # где мы находимся
file document1.txt # что за файл "document.txt" в текущем каталоге?
cat document1.txt # просмотр исходного файла по ссылке
echo "additional text" >> document1.txt # редактирование файла по ссылке
cat ../civil/document1.txt # видно, что оригинал изменился
rm -f ../civil/document1.txt # удаление оригинального документа
ls -l # а ссылка осталась
cat document1.txt # ошибка, т.к. ссылка "висячая" (ссылается на
# несуществующий файл)
echo "new text" >> document1.txt # запись в файл по ссылке;
# будет создан новый файл-оригинал -
# ~/standards/civil/document1.txt
cat document1.txt # переход по ссылке, видно что файл-оригинал существует
cp document1.txt ../document1.txt # копируем ссылку в каталог "standards"
cd ../ # переход в каталог "standards"
ls -l # видно, что скопирован файл-оригинал
file document1.txt # ...не ссылка, а настоящий файл
Найдите легкий способ создания символических ссылок в вашей любимой оконной среде (например, с помощью drag-n-drop); создайте символические ссылки на рабочем столе для наиболее часто используемых приложений.
Жесткие ссылки
Жесткие ссылки чем-то похожи на библиотечную систему карточек – когда для каждой книги есть свой уникальный идентификатор, и зная его – мы можем попросить библиотекаря дать нам эту книгу. При чем названия разных книг могут совпадать, но идентификаторы – никогда (это важный момент, обратите внимание).
Представим, что есть книга, пусть «О мышах и людях». В нашем городе подобные вещи не пользуются особой популярностью, так что предположим что эта книга есть только в одной, скажем, в центральной библиотеке. Но вот мы пришли в местную библиотеку и не нашли там этой книги. Зато там есть карточка, в которой указан код книги. И вот, библиотекарь звонит в другие библиотеки и узнает, что такая книга есть в центральной. Скажем, у нас хороший сервис и вам тут же ее привозят. Вот так работают жесткие ссылки.
Чтобы представление о жестких ссылках было полное, сделаем кое-какие уточнения. В местной библиотеке могут убрать карточку этой книги (скажем, библиотека была государственная, а стала частной). Но книга останется. Если же карточки на эту книгу уберут из всех библиотек – это может означать только одно – самой книги тоже нет (возможно кто-то взял последний экземпляр и не вернул, негодяй такой; помню, я долго не мог взять почитать в институтской библиотеке фантастический роман – его долго не отдавала какая-то девушка. С девушкой я так и не познакомился, но к счастью в файловой системе ваши «книги» всегда будут на месте, лишь бы вы не удалили последнюю «карточку» на нее – об этом ниже).
Рассмотрим теперь, как эта модель функционирует в файловой системе. На самом деле, всегда существует как минимум одна жесткая ссылка на файл. Т.е. сам файл (его содержимое) находится где-то на жестком диске, и у него есть уникальный номер (как книга в Хранилище в модели выше). А имя файла хранится отдельно, в «файловом индексе» (inode) – он соответствует карточке в модели выше. Также в файловом индексе содержится тот же уникальный номер – а поскольку номера одинаковы, то этот файловый индекс и будет являться жесткой ссылкой на само содержимое файла.
Как видим, файловый индекс соответствует карточке, а содержимое – книге. И хранятся они так же раздельно, в разных областях жесткого диска – (карточки – в картотеке, книги – в хранилище). И таким же образом, как в примере с библиотеками, у одного файла может быть несколько имен («карточек» или «файловых индексов») – и столько же жестких ссылок с этими именами.
Если удалить оба файловых индекса (т.е. обе жестких ссылки) – то счетчик жестких ссылок для содержимого файла станет 0, и содержимое файла удалится. Когда говорят «удалить файл» – на самом деле это означает, что есть один файловый индекс, жестко связанный (по уникальному номеру) с содержимым этого файла – и удаляя этот (единственный) файловый индекс – содержимое файла стирается с жесткого диска автоматически.
Практическая работа по жестким ссылкам:
Цитата:В качестве самостоятельного упражнения – попробуйте создать жесткую ссылку на каталог.
# в той же иерархии каталогов, что была создана в работе по симв. ссылкам
# /home/joe/standards
cd civil
echo "123456" > myfile
ls -i myfile # уникальный номер созданного файла
ls -l myfile # число 1 указывает, что у файла одна жесткая
# ссылка
ln myfile ../mechanical/myfile # создаем жесткую ссылку
# пусть имена файлов будут одинаковые
cd ../mechanical/
ls -i myfile # уникальные номера совпадают
ls -l myfile # видим, что у файла уже 2 жестких ссылки
file myfile # при чем файловая система видет напрямую файл
# а не ссылку (как при симв. ссылке)
cp myfile ../myfile # скопируем в каталог standards
cd ../
ls -il myfile # у скопированного файла уже другой уникальный
# номер, и счетчик ссылок – 1, т.е. это новый
# файл а не жесткая ссылка на созданный нами
rm -f civil/myfile # удалим созданный нами в самом начале файл
cd mechanical/
ls -il myfile # количество ссылок стало 1, но номер тот же
Выводы
- Символические ссылки удобно использовать, когда файл-оригинал будет находится по неизменному пути (не будет переноситься в дальнейшем) и его имя будет оставаться также неизменным. Нормально будет сделать символическую ссылку для запуска приложения /usr/bin/local/myapp из каталога рабочего стола, скажем /home/joe/Desktop. Таким образом из графической оболочки (например, KDE) можно будет быстро, одним щелчком мыши, запустить приложение myapp. Такая ссылка будет скорее всего всегда актуальная, т.к. в /usr/bin редко что переименовывается. Также немаловажно, что при обновлении программы myapp (скажем, ее удалят и на ее место скопируют новую копию) – ссылка останется актуальной. Наиболее часто я использую символические ссылки именно в таком ключе – создаю ссылки для приложений на рабочий стол
- Жесткие ссылки удобно использовать при другого рода динамике системы. Например, мы администрируем сервер электронной библиотеки. Есть книга, относящаяся к математике и музыке (назовем ее «Математика и музыка»). При чем оговоримся, что эта книга никогда не будет заменена на более новую с таким же именем файла. Вполне резонно будет сделать жесткие ссылки так, чтобы книга находилась и в разделе «Математика», и в разделе «Музыка»
- Чаще применяют символические ссылки; это связано с динамикой изменения системы. Например, при обновлениях старые файлы удаляются, создаются новые, с теми же именами, и жесткие ссылки не обеспечат правильного поведения
Примеры применения ссылок
- есть разные оболочки (интерпретаторы команд консоли) – bash, dash и т.д. Но всегда есть файл /bin/sh – это как раз символическая ссылка на конкретную программу (выполните команду «file /bin/sh», чтобы убедится в этом). Чтобы изменить реализацию интерпретатора команд в системе – достаточно изменить символическую ссылку sh на соответствующий исполняемый файл
- когда вы выполняете команду «ls -la» и видите каталоги «..» и «.» — это жесткие ссылки, создаваемые системой для предыдущего и текущего каталога соответственно. Сами вы не можете создавать жесткие ссылки на каталоги, а вот система может
- допустим, у вас есть фильм «Into the wild» и саундтреки (OST) к нему. Очевидно, саундтреки относятся и к данному фильму, и к категории «Музыка». Мы хотим видеть эти саундтреки и в каталоге фильма, и в каталоге музыки. Но если положить саундтреки и туда, и туда — это займет в 2 раза больше места на диске, и если вы захотите дополнить или изменить файлы саундтреков — придется делать это в двух местах. Выход из этой ситуации — положить саундтреки в каталог «Музыка» (очевидно, что к этой категории они относятся больше, чем к фильмам) и сделать на весь каталог саундтреков символическую ссылку, которая будет находиться в каталоге с фильмом:
~/Data/Video/Movies/Into the wild/OST -> ~/Data/Music/OST/Into the wild
- также есть замечательный инструмент, к ссылкам отношения не имеющий, но похожий по своей работе: «mount -o bind». Я применял эту команду для выкладывания на свой ftp-сервер музыки, фильмов и т.д. (чтобы выложить файлы на ftp-сервер, необходимо было поместить их в папку /home/ftp/pub, что и делала эта команда без необходимости копировать данные)
источник
ВНИМАНИЕ !
Возможно что-то уже неактуально. Обращайте внимание на даты !
Эта статья опубликована 26 июля 2010-го года !
Прочитано 5653 раз и оставлено 146 комментариев.
#1.