ИТ База знаний
Курс по Asterisk
Полезно
— Узнать IP — адрес компьютера в интернете
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Калькулятор инсталляции IP — АТС Asterisk
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Мягкие и жесткие ссылки в Linux
Продолжаем говорить про символические ссылки
Мы уже рассказывали про мягкие и жесткие ссылки в Linux, и данная статья посвящена их более глубокому изучению. Ссылки в операционной системе Linux бывают 2-х типов мягкие и жесткие. Если провести аналогию с операционной системой Windows, то там мы в основном работаем с мягкими ссылками, символическими ярлыками. Но в операционной системе Windows есть и жесткие ссылки, просто они очень глубоко спрятаны внутри операционной системы. В статье будет рассказано:
- Как идентифицировать тип ссылки
- В чем разница между мягкой и жесткой ссылкой
- В чем разница между копирование и создание ссылки
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
Итак, смотрим в домашнюю директорию пользователя. Я заранее создал файл и 2 ссылки жесткую и мягкую указывающие на данный файл.
Основной файл file.txt , жесткая ссылка hard.txt на файл file.txt и мягкая ссылка soft.txt на файл file.txt . Как можно заметить символические (мягкие) ссылки в оболочке, обычно, подкрашиваются ярко голубым цветом и показывают на какой файл она ссылается. Можно еще интересную вещь заменить основной файл весит 38 килобайт и жесткая ссылка столько же весит. Мягкая ссылка – это всего лишь ярлык и весит всего 8 килобайт. Посмотрим, что внутри файла основного. Файл содержит фразу.
Команда ls с ключем –li может отображать inodes. В результате ввода команды появился еще один столбец впереди. В данном столбце и отображается номер inodes, т.е идентификатор файла, индексный дескриптор, местонахождение файла на диске, метка файла.
В нашем же случае номера inodes у файла и у жесткой ссылки совпадает. Т.е жесткая ссылка указывает на то же место, где находиться основной файл, в то же самое место на жестком диске. Мягкая же ссылка, сама по себе является отдельным файлом и у нее совершенно другой inode. А также можно видеть, что у данного файла в правах появилась буква l , которая указывает что это символьная ссылка. Причем попробовав просмотреть содержимое жесткой и мягкой ссылки, мы получим одинаковый результат. Все показывает на один и тот же файл.
Если мы попробуем дописать, какие-нибудь изменения в файл. Например, echo Hello>> file.txt
Получим один и тот же результат. Возьмем и переименуем наш основной файл mv file.txt newfile.txt .
Теперь мы можем увидеть, что ссылка мягкая у нас стала красной (Битой). Потому что, мягкие ссылки опираются на имя файла. Причем не просто на имя файла, а на полное имя файла. А жесткая ссылка, как была, так и осталась работоспособной. Потому, что она указывает на один и тот же inode, потому что она указывает на то место где данный файл находиться. И если мы утилитой cat скажем показать жесткую ссылку в выводе мы получим исходный файл, а мягкая ссылка выдаст нам ошибку. Основная разница между жесткой ссылкой и мягкой, заключается в том, что мягкая опирается на имя файла. А жесткая указывает на физическое место, определяемое дескриптором где находиться файл.
Создаются такие ссылки достаточно просто, командой ln с указанием основного файла и ссылки. Например, ln file.txt hard.txt . При создании мягкой ссылки добавляется ключик –s . Будет выглядеть примерно так — ln –s file.txt soft.txt . При создании ссылки, можно объекты указывать без расширения.
Т.к. жесткая ссылка у нас привязана к inode, то ее нельзя использовать с несколькими файловыми системами. Если у вас есть другой жесткий диск премонтированый в данную файловую систему, то вы не сможете создать жесткую ссылку из данной системы к премонтированному жесткому диску. Потому, что это все опирается на inode, а inode справедливы для конкретной файловой системе. Поэтому в операционной системе Windows все ссылки по умолчанию мягкие. Пригодиться это может где угодно. Например, мы в своей домашней директории можем создать ссылки на все свои важные папки или данные. Очень часто символические ссылки используются для администрирования. Операционной системы Linux. Например, для команд, если пользователь не хочет знать номер версии или дополнительные ключи, он может просто получать доступ к различным версиям просто используя ссылки.
Также стоит упомянуть ситуацию с папками.
Создадим папку — mkdir Folder . Попробуем создать жесткую ссылку на данную папку — ln Folder folder.lnk , данная команда выдаст ошибку указывая на то, что нельзя создать жесткую ссылку на папку, но, а если мы захотим создать мягкую (символическую ссылку), то проблемы не возникнет — ln –s Folder folder.lnk .
Хорошим тоном при создании ссылок символических это указание на полный путь файлу, т.к привязка идет к имени файла и при создании если указать относительны, мы можем столкнуться с ситуацией, когда получившаяся ссылка будет битой. Например, когда мы хотим создать ссылку на файл и положить ее во внутрь другие папки ln –s /home/siadmin/file.txt Folder/ . данный вариант будет рабочим.
Разница между копирование файла и созданием ссылки. Когда копируем файл мы фактически создаем другой файл со всем его содержимым, а когда мы создаем ссылку – это некий ярлык на файл. Скопируем файл file.txt в newfile.txt и на file.txt создадим жесткую ссылку. Когда мы смотрим вывод команды ls –l по папке то визуально копию мы не отличим от жесткой ссылки, если мы конечно об этом не знаем. А отличие мы увидим только если мы посмотрим на inodes.
Как мы видим номера inode у файла и жесткой ссылки совпадают, причем мы не знаем, что из них первично. Можно заметить столбец с цифрами после указания прав на объекты, он показывает сколько ссылок жестких есть на данный inode. Создадим еще одну жесткую ссылку ln file.txt hard1.txt . Теперь если сделать вывод ls –li , то мы увидим цифру 3. Почему так происходит? Удалением файла у нас по умолчанию является действие, которое обнуляет количество всех жестких ссылок. Если мы удалим файл исходный file.txt . и посмотрим вывод то мы увидим, что если есть мягкие ссылки, то они прекратят работать, а файлы hard.txt и hard1.txt остались.
Более того, если обратиться к этим жестким ссылкам, например, с помощью утилиты просмотра cat hard.txt , то мы увидим текст, который был у нас изначально в файле.
Это происходит потому, что сам файл — это некоторое пространство занятое на диске, а имя файла и путь к нему – это и есть жесткая ссылка. Поэтому любой файл это есть жесткая ссылка на место на диске. Мы можем создать к нашему inode сколько угодно ссылок и пока мы их всех не удалим наш файл будет на месте.
Мини — курс по виртуализации
Знакомство с VMware vSphere 7 и технологией виртуализации в авторском мини — курсе от Михаила Якобсена
Источник
Что такое hard link linux
В статье сделана попытка объяснить на простых примерах понятие ссылок в файловой системе, а также в каких случаях их стоит применять. Взято на Хабре тут: http://habrahabr.ru/blogs/linux/99746/.
Далее разговор пойдет о Unix-like файловых системах, как ext3, ext4 и т.д., потому что концепция ФС Windows не позволяет так же прозрачно работать со ссылками, как ФС Unix-систем (см. «Символические ссылки в Windows»). Максимум, что может предоставить продвинутым пользователям система Windows – механизм «ярлыков». Хотя и тут они не всё продумали – как-то раз в школе приятель скинул мне на дискету много-много больших игр, каждая из которых должна была занимать, по идее, CD-диск. Думаю, вы догадались, что я обнаружил на дискете. Так что разработчикам Windows приходится несладко – всё время нужно думать, как оградить пользователя от самого себя. Напротив, создатели Unix-систем постоянно как бы намекают нам: используйте ссылки!
[Символические ссылки (soft links)]
Чтобы понять, что такое символические ссылки – представьте себе каталог бумажной документации (куча полок с документами). Пусть есть полки «Строительные стандарты» и «Машиностроительные стандарты». Но как поступить, если у нас есть стандарт, относящийся к проектированию механосборочных цехов? Ведь этот стандарт может понадобиться и строителям и в машиностроении.
Первый подход состоит в том, чтобы положить этот документ в секцию «Строительные», а в секции «Машиностроение» оставить заметку, что документ с таким названием находится в секции «Строительные стандарты». Такой подход применим, если документ более относится к строительной тематике, нежели к машиностроению.
Это и называется «символическая ссылка» – файл помещается в каталог («Строительные»), а в другом каталоге («Машиностроение») создается специальный файл, указывающий на документ в каталоге «Строительные». При попытке прочитать или редактировать файл-ссылку, файловая система перенаправит нас на файл-оригинал. При удалении символической ссылки – исходный файл остается. Т.е. всё как в приведенной выше аналогии с полками. Если удалить исходный документ – ссылка останется на месте.
Недостаток такого подхода в том, что при перемещении исходного файла, ссылка не изменит автоматически путь на новый. Еще недостаток – не всегда можно определить, в какой каталог (на какую полку) положить исходный файл – иногда файл может относиться одинаково ко двум или даже трем категориям. От этих недостатков свободны жесткие ссылки.
Практическая работа по символическим ссылкам:
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); создайте символические ссылки на рабочем столе для наиболее часто используемых приложений.
[Жесткие ссылки (hardlinks)]
Жесткие ссылки чем-то похожи на библиотечную систему карточек – когда для каждой книги есть свой уникальный идентификатор, и зная его – мы можем попросить библиотекаря дать нам эту книгу. При чем названия разных книг могут совпадать, но идентификаторы – никогда (это важный момент, обратите внимание).
Представим, что есть книга, пусть «О мышах и людях». В нашем городе подобные вещи не пользуются особой популярностью, так что предположим что эта книга есть только в одной, скажем, в центральной библиотеке. Но вот мы пришли в местную библиотеку и не нашли там этой книги. Зато там есть карточка, в которой указан код книги. И вот, библиотекарь звонит в другие библиотеки и узнает, что такая книга есть в центральной. Скажем, у нас хороший сервис и вам тут же ее привозят. Вот так работают жесткие ссылки.
Чтобы представление о жестких ссылках было полное, сделаем кое-какие уточнения. В местной библиотеке могут убрать карточку этой книги (скажем, библиотека была государственная, а стала частной). Но книга останется. Если же карточки на эту книгу уберут из всех библиотек – это может означать только одно – самой книги тоже нет (возможно кто-то взял последний экземпляр и не вернул, негодяй такой; помню, я долго не мог взять почитать в институтской библиотеке фантастический роман – его долго не отдавала какая-то девушка. С девушкой я так и не познакомился, но к счастью в файловой системе ваши «книги» всегда будут на месте, лишь бы вы не удалили последнюю «карточку» на нее – об этом ниже).
Рассмотрим теперь, как эта модель функционирует в файловой системе. На самом деле, всегда существует как минимум одна жесткая ссылка на файл. Т.е. сам файл (его содержимое) находится где-то на жестком диске, и у него есть уникальный номер (как книга в Хранилище в модели выше). А имя файла хранится отдельно, в «файловом индексе» (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
Источник
