21 июля 2010 в 22:27

Простое объяснение символических и жестких ссылок

В статье я попытаюсь объяснить на простых примерах понятие ссылок в файловой системе, а также в каких случаях их стоит применять. Материал рассчитан на новичков в системе Linux (думаю, для профи это весьма банальные вещи).


Далее разговор пойдет о Unix-like файловых системах, как ext3, ext4 и т.д., потому что концепция ФС Windows не позволяет так же прозрачно работать со ссылками, как ФС Unix-систем (см. «Символические ссылки в Windows»). Максимум, что может предоставить продвинутым пользователям система Windows – механизм «ярлыков». Хотя и тут они не всё продумали – как-то раз в школе приятель скинул мне на дискету много-много больших игр, каждая из которых должна была занимать, по идее, CD-диск. Думаю, вы догадались, что я обнаружил на дискете. Так что разработчикам Windows приходится несладко – всё время нужно думать, как оградить пользователя от самого себя. Напротив, создатели Unix-систем постоянно как бы намекают нам: используйте ссылки!

Символические ссылки


Чтобы понять, что такое символические ссылки – представьте себе каталог бумажной документации (куча полок с документами). Пусть есть полки «Строительные стандарты» и «Машиностроительные стандарты». Но как поступить, если у нас есть стандарт, относящийся к проектированию механосборочных цехов? Ведь этот стандарт может понадобиться и строителям и в машиностроении.

Первый подход состоит в том, чтобы положить этот документ в секцию «Строительные», а в секции «Машиностроение» оставить заметку, что документ с таким названием находится в секции «Строительные стандарты». Такой подход применим, если документ более относится к строительной тематике, нежели к машиностроению.

image

Это и называется «символическая ссылка» – файл помещается в каталог («Строительные»), а в другом каталоге («Машиностроение») создается специальный файл, указывающий на документ в каталоге «Строительные». При попытке прочитать или редактировать файл-ссылку, файловая система перенаправит нас на файл-оригинал. При удалении символической ссылки – исходный файл остается. Т.е. всё как в приведенной выше аналогии с полками. Если удалить исходный документ – ссылка останется на месте.

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

Практическая работа по символическим ссылкам:

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); создайте символические ссылки на рабочем столе для наиболее часто используемых приложений.

Жесткие ссылки


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

Представим, что есть книга, пусть «О мышах и людях». В нашем городе подобные вещи не пользуются особой популярностью, так что предположим что эта книга есть только в одной, скажем, в центральной библиотеке. Но вот мы пришли в местную библиотеку и не нашли там этой книги. Зато там есть карточка, в которой указан код книги. И вот, библиотекарь звонит в другие библиотеки и узнает, что такая книга есть в центральной. Скажем, у нас хороший сервис и вам тут же ее привозят. Вот так работают жесткие ссылки.

image

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

Рассмотрим теперь, как эта модель функционирует в файловой системе. На самом деле, всегда существует как минимум одна жесткая ссылка на файл. Т.е. сам файл (его содержимое) находится где-то на жестком диске, и у него есть уникальный номер (как книга в Хранилище в модели выше). А имя файла хранится отдельно, в «файловом индексе» (inode) – он соответствует карточке в модели выше. Также в файловом индексе содержится тот же уникальный номер – а поскольку номера одинаковы, то этот файловый индекс и будет являться жесткой ссылкой на само содержимое файла.

image

Как видим, файловый индекс соответствует карточке, а содержимое – книге. И хранятся они так же раздельно, в разных областях жесткого диска – (карточки – в картотеке, книги – в хранилище). И таким же образом, как в примере с библиотеками, у одного файла может быть несколько имен («карточек» или «файловых индексов») – и столько же жестких ссылок с этими именами.

image

Если удалить оба файловых индекса (т.е. обе жестких ссылки) – то счетчик жестких ссылок для содержимого файла станет 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, но номер тот же


В качестве самостоятельного упражнения – попробуйте создать жесткую ссылку на каталог.

Выводы

  1. Символические ссылки удобно использовать, когда файл-оригинал будет находится по неизменному пути (не будет переноситься в дальнейшем) и его имя будет оставаться также неизменным. Нормально будет сделать символическую ссылку для запуска приложения /usr/bin/local/myapp из каталога рабочего стола, скажем /home/joe/Desktop. Таким образом из графической оболочки (например, KDE) можно будет быстро, одним щелчком мыши, запустить приложение myapp. Такая ссылка будет скорее всего всегда актуальная, т.к. в /usr/bin редко что переименовывается. Также немаловажно, что при обновлении программы myapp (скажем, ее удалят и на ее место скопируют новую копию) – ссылка останется актуальной. Наиболее часто я использую символические ссылки именно в таком ключе – создаю ссылки для приложений на рабочий стол
  2. Жесткие ссылки удобно использовать при другого рода динамике системы. Например, мы администрируем сервер электронной библиотеки. Есть книга, относящаяся к математике и музыке (назовем ее «Математика и музыка»). При чем оговоримся, что эта книга никогда не будет заменена на более новую с таким же именем файла. Вполне резонно будет сделать жесткие ссылки так, чтобы книга находилась и в разделе «Математика», и в разделе «Музыка»
  3. Чаще применяют символические ссылки; это связано с динамикой изменения системы. Например, при обновлениях старые файлы удаляются, создаются новые, с теми же именами, и жесткие ссылки не обеспечат правильного поведения

Примеры применения ссылок

  • есть разные оболочки (интерпретаторы команд консоли) – 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, что и делала эта команда без необходимости копировать данные)

Список использованной литературы

  1. http://habrahabr.ru/blogs/linux/99653/
  2. Нейл Мэтью, Ричард Стоунс. Основы программирования в Linux, 4-е издание. Глава 3


P.S. Я знаю, что картинки — face palms, но, как сказал бы доктор МакКой: «Я врач, а не художник» :)
+40
26652
133
skb7 15,5

комментарии (107)

0
pfactum, #
Картинок нет.
0
pfactum, #
Ой, уже появились. Извиняюсь.
+42
homm, #
Не хотел бы я увидеть «сложное».
+2
hshhhhh, #
Неужели вы ничего не поняли?
+25
Frosty, #
Совершенно, и это учитывая 4-летний опыт работы в линуксах. Если бы не было изначального представления о ссылках, то не понял бы совершенно ничего. Статься излишне пестрит «доступными примерами из жизни». Для кого она сделана? Для новичков в Linux или для новичков в компьютерах? Зачем все эти книги, библиотеки, библиотекарши, строительные стандарты и полки с документами? Столько лишних сущностей, только сильнее запутывающих человека.
В первую очередь в статье, описывающей разницу между двумя понятиями надо описать эту разницу при помощи разницы свойств обоих видов ссылок, можно даже таблицей, где в 5-10 пунктов поместится вся эта 6-страничная стена текста.
+1
FractalizeR, #
Согласен. 12 килобайт текста, не говоря уже о картинках. И это все только для того, чтобы объяснить, что такое ссылка в FS?
0
Alroniks, #
а пробовали объяснять родителям устройство компа компьютерными терминами? многое они поняли?

Для нас с вами, которые с детства практически знакомы с компьютерами (я правда только с 8 класса) понять не проблема, нагуглим в случае чего. Но новичкам действительно не просто взять и вот сразу понять что такое симлинк и что такое хардлинк. Примеры из жизни как раз позволяют понять логику работы этих самых ссылок, заставляют думать человека, а не просмотреть таблицу и сказать «ну вроде понятно».
0
hazg, #
Да. Пробовал.

— А вот тут что?
— Это считает, это показывает, это запоминает. (тыкаем пальцем) Сюда втыкать, чтобы работал джойстик, а эта штучка — ключ, чтобы 1с работала. Понятно? И не надо 40 раз нажимать на ярлык. Он просто не успел открыться. Никогда! Понятно?
— Ну да.

Статья, да простит меня автор — не раскрывает тему си..., сорри, ссылок. Она ее покрывает туманом войны и тайны.

Человеку нужно понять зачем, а не путаться в параграфах из серии: если Вы не достаточно умны, перейдите к параграфу 1.1.2 «я туповат»
1.1.2 Я туповат

Если вы ничего не поняли, перейдите к иллюстрированному приложению «я совсем тупой».

Короче, одной гифкой можно обойтись для объяснения.
НЛО прилетело и опубликовало эту надпись здесь
+30
desterman, #
Раньше мне казалось, что я понимаю разницу между символическими и жёсткими ссылками. Теперь я понимаю, что нифига не понимаю ваше «простое объяснение».
+38
Mezomish, #
Грубо говоря, символическая ссылка — это ссылка на имя файла. Вне зависимости от того, что именно лежит на диске под этим именем.
А жёсткая ссылка — это ссылка на саму область диска, содержащую файл (информацию). Жёсткая ссылка — это как ещё одно (полностью равноправное) имя файла.
+18
Kakysha, #
ваш комментарий вполне тянет на «простое объяснение символических и жестких ссылок». Спасибо!
Но никак не сам пост )
+7
Mezomish, #
Если на простом примере, то примерно так:

Создадим файл file_a а содержимым «aaa»:
$ echo "aaa" > file_a

Создадим на него 2 ссылки: символическую и жёсткую:
$ ln -s file_a link1
$ ln file_a link2

Попробуем достучаться до файла по обеим ссылкам:
$ cat link1
aaa
$ cat link2
aaa

Всё нормально. Теперь удалим оригинальный файл и попробуем достучаться ещё раз. Первая ссылка окажется битой, а по второй ссылке по-прежнему находится файл с содержимым «aaa»:
$ rm file_a
$ ls
link1 link2
$ cat link1
cat: link1: No such file or directory
$ cat link2
aaa

Снова создадим файл с именем file_a, но с другим содержимым:
$ echo "bbb" > file_a

А теперь снова попробуем достучаться по ссылкам. Первая ссылка снова валидна, и по ней будет находиться файл с содержимым «bbb». А по второй ссылке находится всё тот же файл с содержимым «aaa».
$ cat link1
bbb
$ cat link2
aaa
+4
grokinn, #
самое простое объяснение — если стереть файл то симфолическая ссылка перестанет работать, место на диске освободится, а жесткая ссылка продолжит работать, файл останется на месте, место на диске не изменится.
+1
onk, #
еще «сборщик мусора» сюда приписать — закончились ссылки на данные и только тогда данные будут удалены (чаще всего помечены как освободившиеся)
+29
Gorthauer87, #
А что там понимать? Жесткая ссылка — это просто дополнительное имя файла, работает она в пределах одной физической файловой системы, при этом имя оригинала может меняться как угодно, его можно даже удалить, а жесткая ссылка останется, а символическая ссылка это просто ссылка на файл в пределах virtual file system и её аналогов, соответственно она не чувствительна к фс, на которой файл лежит, но чувствительна к его полному названию
+5
hshhhhh, #
У вас слишком маленькое и доступное объяснение.
+12
netto, #
Какое-то объяснение «для лохов». Ни одной формулы.
+6
Zagrebelion, #
ntfs замечательно работает с ссылками.
–2
skb7, #
Не спорю. Я лишь написал, что работа со ссылками в NTFS не так прозрачна, а именно — для этого требуются дополнительное ПО, не входящее в состав ОС, и не все программы реализованы корректно (как я могу судить по этой статье vpbar.habrahabr.ru/blog/51294/)
+1
maxpelevin, #
«а именно — для этого требуются дополнительное ПО»

В Windows Vista/7 не требуется
0
Gorthauer87, #
Ну консольные утилиты в Винде это совсем не userfriendly, вот когда в проводнике будут удобные действия, тогда скажем, что не требуется доп ПО
–4
bolk, #
Powershell посмотрите. Времена изменились.
0
Malamut, #
Ничего не изменилось. После bash PS выглядит несколько, эээ… убого. Без сомнения огромный рывок вперёд, но как всегда — с включёнными тормозами.
–1
bolk, #
Славная шутка.

Позвольте спросить, сколько вы программируете на bash и PS? С bash я познакомился ещё в 98-м. С тех пор пересаживался и на tcsh и на zsh, но большее всего времени я провёл на bash. На PS в первый раз взглянул около года назад, с тех пор иногда на нём программирую.

Так вот. Что «после bash PS выглядит убого» это очень смешная шутка. Потому что это не так. «после PS1 bash выглядит убого» — куда ближе к истине. Я ещё никак не посмотрю PS2, но, думаю, bash будет выглядеть не просто убого, а очень плохо.

Что вам показалось убогим в PS после bash? И, повторяю свой вопрос, сколько вы программируете на том и другом?
–1
bolk, #
Товарищи минусующие, вам есть что сказать по существу? У вас какой-то другой опыт использования того и другого? Или вы только «слышали звон»?
0
Gorthauer87, #
Для начала почему баш и компания стартуют сразу, а пс чуть ли не 5 секунд грузится? Это очень злит, когда надо окно быстро открыть отпечатать команду и закрыть.
–2
bolk, #
Я не знаю где он у вас грузится чуть ли не пять секунд, у меня, в Windows 7, загружается куда меньше чем за секунду.
0
Gorthauer87, #
Мимо… Когда там у PS из коробки появится нормальный гуевый эмуль терминала?
–1
bolk, #
У шелла эмуль терминала? Вы ничего не путаете? По-вашему, в Linux bash несёт такую же функцию?
0
Gorthauer87, #
Ну хорошо, для шелла когда наманое окно терминала появится? cmd.exe и его аналог для повершелла — полное угрёбище неюзабельное
–1
bolk, #
Что такое «нормальное окно терминала»?
+3
Gorthauer87, #
Опять 25… И это мне говорит человек юзавший баш в Линуксе, что-то я начинаю в этом сомневаться.
Ну хорошо, где в cmd.exe и его аналоге для PS табы? Где там сохранение хистори между сеансами? Где там поддержка различных профилей? Где там нормальный автокомплит параметров?
–1
bolk, #
Опять 25… И это мне говорит человек юзавший баш в Линуксе, что-то я начинаю в этом сомневаться.
Откуда мне-то знать что вы считаете признаком хорошего терминала.
Ну хорошо, где в cmd.exe и его аналоге для PS табы?
Причём тут bash? Что, bash табы делает?
Где там сохранение хистори между сеансами?
Делается отдельным скриптом.
Где там поддержка различных профилей?
msdn.microsoft.com/en-us/library/bb613488(VS.85).aspx
Где там нормальный автокомплит параметров?
Там нормальный автокомплит, в отличие от bash, где его «из коробки» нет.
+1
Gorthauer87, #
>Причём тут bash? Что, bash табы делает?

Я блин про одно а мне отвечают про другое. Ну спасибо, оч конструктивно. Но от факта, что окошко cmd.exe и его аналог для PS убого и неюзабельно таким макаром не уйдешь.

>Делается отдельным скриптом.

Костыль

>Там нормальный автокомплит, в отличие от bash, где его «из коробки» нет.

Хотите сказать, что bash_completion ещё в каких-то отсталых системах по умолчанию не ставят?
–1
bolk, #
Я блин про одно а мне отвечают про другое. Ну спасибо, оч конструктивно. Но от факта, что окошко cmd.exe и его аналог для PS убого и неюзабельно таким макаром не уйдешь.
Да просто понесло вас куда-то в сторону. Мы сравнивали bash и PS, ничего кроме этого я сравнивать не собираюсь.
Костыль
Костыль или нет, а я могу хранить историю так, как мне удобно.
Хотите сказать, что bash_completion ещё в каких-то отсталых системах по умолчанию не ставят?
Во-первых, это не bash, во-вторых, в каких-то системах ещё не ставят.
0
Mezomish, #
>Да просто понесло вас куда-то в сторону. Мы сравнивали bash и PS, ничего кроме этого я сравнивать не собираюсь.

Видите ли, в чём дело: кто-то может изобрести охрененный язык, начисто лишённый недостатков всех существующих языков. И утечек памяти-то в нём не будет, и требования к памяти будут минимальными, и скорость будет офигенной, и так далее и так далее. Но! Если под него не будет вменяемой IDE, не будет нужных библиотек и прочих совершенно необходимых вещей, то он нафиг никому не будет нужен.

К чем я это? А к тому, что рассматривать «сферическое скриптование в вакууме» в отрыве от инфраструктуры, которая его окружает — совершенно неблагодарное занятие.
–1
bolk, #
Не спорю.

Но мы-то не про среду начинали разговор, а про то, что в Windows (якобы) всё плохо с консольными утилитами.
+1
Gorthauer87, #
А теперь перечитайте то, что я написал, а написал я то, что юзание этих самых консольных утилит ну очень далеко от user friendly. Разницу чуете?
Мне от консольных утилит всего ничего нужно, но вот окошко терминала меня каждый раз в уныние ввергает — оно ужасно.
–1
bolk, #
Нет, вы написали не так. Вы написали, что «консольные утилиты в винде не user friendly». Я внимательно читаю, что люди пишут.
–1
Gorthauer87, #
А теперь мы к словам будем придираться и уходить от ответа… На демагога выучиваемся?
–1
bolk, #
Научитесь грамотно формулировать свои мысли, различать нюансы родного языка, никто не будет «придираться» и «уходить».

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

Не кажется ли вам, что тут что-то не так?
0
Gorthauer87, #
man 100 правил хорошего демагога
На сией ноте удаляюсь
–1
bolk, #
man 100 правил владения русским языком.
На сей ноте удаляюсь и я.
+1
xn__p2a, #
Где там сохранение хистори между сеансами?
Делается отдельным скриптом.
Что ж не принтскрином-то?
0
bolk, #
Вас как-то не смущает, что автокомплит параметров bash делается отдельным скриптом. А тут-то почему такая ирония?
0
bolk, #
fsutil, кажется, ещё в 2000-й есть. С её помощью можно создавать жёсткие ссылки.
+3
Zagrebelion, #
Вы написали, что " Максимум, что может предоставить продвинутым пользователям система Windows – механизм «ярлыков»".

Впрочем, закончу оффтоп в этом блоге. ;)
+1
ShadowMaster, #
А fsutil на что?
0
skb7, #
Оно только хард-линки может, судя по этому:
www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil.mspx?mfr=true

Компа с виндой нет, чтобы проверить
0
Busla, #
А зачем вы судите по этой статье, если там в предисловии явно указано, что рассматривается только некоторый ограниченный функционал: «далее буду говорить о тех символических ссылках которые делаются программой Junction» и старая ОС.
Почему бы не откпать статью про Win98 и на её основе делать выводы? ;)
+12
xn__p2a, #
> ntfs замечательно работает с ссылками.

Поддержка хардлинков и симлинков на NTFS в Windows — это вообще отдельная песня.

В попытке следования стандартам POSIX на файловой системе NTFS v1.x (в WinNT3.x/NT4) реализовали механизм хардлинков. И они в целом следовали принципам работы хардлинков в юниксовых файловых системах, т.е. были их аналогами.

Потом вышла Win2k и NTFS там обновилась до версии 3.0 — и там уже кроме хардлинков стали поддерживаться так называемые junctions (junction points). Причём во многих источниках указывалось, что это теперь на NTFS появились симлинки, но в терминологии MS они называются junctions. Даже в официальных статьях Microsoft упоминалось, что у MS теперь есть своя реализация Symbolic Links.
В отличие от полноценных юниксовых симлинков junctions можно было создавать только для каталогов, но не для обычных файлов.
Но во многих статьях понятия junctions и NTFS symlinks использовались как синонимы.

Потом появилась NTFS v3.1 (вместе c WinXP), но в плане хардлинков и симлинков там ничего не поменялось.
С тех пор версия NTFS не менялась, т.е. в WinXP, Win2k3, WinVista, Win2008, Win7, Win2008-R2 — везде используется версия файловой системы NTFS v3.1 (хотя частенько ошибочно версию NTFS указывают по версии WinNT, т.е. 5.1, 5.2, 6.0… но это в действительности одна версия v3.1)

Однако в WinVista (а потом и в Win7), было объявлено, что теперь в Windows есть настоящие полноценные симлинки, которые теперь можно делать не только на каталоги, но и на обычные файлы.
Но симлинки эти реализованы не на файловой системе, а средствами ОС. В Windows искусственно введено ограничение на создание симлинков только администраторами. А также допускается создание симлинков даже на файловой системе FAT32 (т.к. реализованы они не на ФС).
Поэтому о полноценной поддержке симлинков на NTFS говорить неверно, т.к. это вовсе не заслуга файловой системы.

И с момента выхода WinVista MS уже тщательно открещивается от попытки назвать junction points симлинками и старается разделять эти понятия.

В итоге в Windows кроме привычных всем двух сущностей: HardLinks (жёсткие ссылки) и SymLinks (символьные ссылки) есть ещё и своя самобытная сущность — junctions, которая по сути представляет собой урезанные по возможностям симлинки.

Но самый главный пробел Microsoft в реализации поддержки симлинков и хардлинков — это отсутствие удобных встроенных визуальных средств для работы с ними. Т.е. во встроенном файловом менеджере Explorer работать с ними удобно и понятно до сих пор нельзя. Раньше для этого были только убогие консольные утилиты из Resource Kit, а также сторонние консольные утилиты (junctions.exe от Марка Руссиновича, различные сторонние сборки ln.exe, файловый менеджер FAR Manager и некоторые другие). В WinVista/Win7 появилась встроенная консольная утилита для симлинков. Но нормальной поддержки в Explorer до сих пор нет.
0
YaakovTooth, #
О, теперь всё встало на свои места. :)

Спасибо. :)
+9
v_k, #
Покорнейше прошу прощения, но очень похоже на описание препода, который ведет лабы. Чтобы загеммороить девственный мозг, а в конце произнести: «ну в целом, жесткая ссылка удаляется вместе с исходным файлом, а символическая нет».
+1
skb7, #
Не знаю насчет преподов, я не на ИТ-специальности учился, иногда вот жалею что никто мне не «геммороил» мозг такими вещами, теперь приходится самому разбираться, начиная с азов
+3
CLR, #
Да все вы правильно рассказали, с таким подходом человек с большей вероятностью запомнит эти аналогии, примеры и следствия. А мимолетная фраза очень легко забывается и искажается.
+2
hazg, #
Быстрее всего разница запоминается, когда жесткую ссылку стираешь.
0
Gorthauer87, #
Ну в теории ничего не должно страшного случиться. Был даже скрипт, который одинаковые файлы искал и заменял их хардлинками
0
ivan386, #
Я как раз таким скриптом недавно прошёлся по диску C:\ с XP на борту. XP перестал видеть некоторые dll'ки. Regserv32 вообще сума сходил(забивал копиями всю память) при установке программы или компиляции.

В общем «обновил» я XP с установочного диска и проблема пропала вместе с хардлинками. Правда теперь другие вылезают ))
0
Mezomish, #
И что в этом случае должно произойти?
0
xn__p2a, #
Ну если удаляется последняя жёсткая ссылка на файл, то файл считается удалённым и эта область данных на ФС помечается как свободная.
0
Mezomish, #
Если она последняя — тогда конечно.
0
hazg, #
Попробую по-другому: берем свой самый ценный бекап всех баз\исходников\телефонов, архивируем в ~/moe_vse.tar.gz и делаем жесткую ссылку под названием ~/test/hard_link.tar.gz…

Теперь удаляем ~/moe_vse.tar.gz и ложимся спать. На утро в директории ~/test/ будет файл hard_link.gz с исходниками, базами и телефонами.

Конечно многое зависит от будильника и младшего брата )))))))))
+1
xn__p2a, #
Считать хардлинк бэкапом — это очень наивно.
Любое изменение (редактирование/частичное стирание/перезапись) — изменят сами данные. И они такие же измененные будут доступны по всем хардлинкам.
Любой крах диска или файловой системы — убьют сами данные (они же в единственном экземпляре).
0
hazg, #
Мда. Плохой пример. Хотелось как лучше, получилось как всегда )))

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

Для наглядности жесткую ссылку наверно лучше сделать /var/ftp/pub/Пререрасход_траффика_OOO_IGG(НЕ УДАЛЯТЬ).csv -rw-r--r--

Не подумал. Каюсь.

Собственно, из за этих мелочей хороших учителей и называют хорошими. Я не претендую.
+2
Mezomish, #
>жесткая ссылка удаляется вместе с исходным файлом, а символическая нет

Жёсткая ссылка удаляется вместе с исходным файлом только в том случае, если эта ссылка — последняя. А если есть другие ссылки, то ничего не произойдёт.
НЛО прилетело и опубликовало эту надпись здесь
+3
RainFall, #
Можно с кавычками еще.
+1
skb7, #
При чем пробел экранируется при автодополнении по Tab :) Можно еще двойные кавычки использовать:
ln -s "/mnt/win/Documents and Settings/serguei/Мои документы" /home/englishextra/Documents
–1
sanix, #
Вот как надо: =)

ln -/mnt/win/Document"s a"nd\ Settings/serguei/Мои' 'документы /home/englishextra/Documents
0
Malamut, #
Символические ссылки обычно делают наоборот — из какого-нибудь левого каталога в /usr/bin или /usr/sbin, чтобы иметь возможность запускать простой командой. А на десктоп правильные люди кидают .desktop файлы, которые по сути похожи на ярлыки Windows, только сильно лучше))
0
VolCh, #
По-моему, мало уделено внимания различию между абсолютными и относительными путями в симлинках (да и само это слово можно было бы добавить, как синоним символической ссылки, чтоб новички не путались :) )
+12
stogerc, #

То есть «Имя файла 2» просто является вторым именем для «файл 1»
+2
Aineko, #
статью еще не читал, но эта картинка — самое наглядное и короткое объяснение из всех, что я видел.
0
stogerc, #
Картинку сделал в inkscape за 5 минут, представляю, сколько автор писал эту статью. Но автору всё же плюс за старание.
0
stogerc, #
Не дописал:
То есть «Имя файла 2» просто является вторым именем для «файл 1» в случае с жесткими ссылками и, как и «имя файла 1», ссылается на «файл 1», а в случае с символическими «имя файла 2» просто ссылается на «имя файла 1», которое, в свою очередь, ссылается на «файл 2».
+8
mukizu, #
Теперь понятно почему многие статьи в русской вики такие какие они есть…

+1
Malamut, #
Напишите лучше!
0
mukizu, #
lurkmore.ru/Сперва_Добейся?

Лучше уже до меня 10 раз написали
0
ivan386, #
Думаю в данном случае это просто призыв отредактировать статьи в вики в соответствии с вашем видением. Если что то кому то не понравится в вашей редактуре это просто откатят.
–2
andruhan, #
статья автора перегружена, на мой взгляд.
мне вот этого объяснения вполне хватило, чтобы понять суть хард и софт линков:
linuxgazette.net/105/pitcher.html
НЛО прилетело и опубликовало эту надпись здесь
+7
r13, #
Друх! Статья восхитительна и ужасна одновременно. Это, например, как смотреть на какающего тираннозавра Рекс, да не обидятся палеонтологи.
0
skb7, #
Вот как, Джим?
+2
semenovs, #
Если честно то для меня в доках по POSIX проще написано чем написали Вы :)

Жесткая ссылка на файл неотличима от его исходного имени; ни одна из жестких ссылок не является более «реальным именем» для файла, чем любая другая.
Операционная система следит за тем, сколько жестких ссылок обозначают файл в каждый данный момент времени. Когда файл впервые создается, у него имеется одна ссылка. Каждая новая жесткая ссылка увеличивает это число, а каждая удаленная — уменьшает. Когда исчезает последняя ссылка на файл и файл закрывается, он прекращает свое существование.


Символическая ссылка — это файл особого вида, который содержит в качестве данных путевое имя. Когда этот файл открывается, операционная система рассматривает его содержимое как заменяющие символы для данного путевого имени и заставляет ядро еще немного порыскать по дереву каталогов, используя новое имя.
+2
r3s3t, #
Я ничего не понял.
НЛО прилетело и опубликовало эту надпись здесь
0
NastyIII, #
Символическая ссылка — это не аналог ярлыка. Попробуй в ярлык что-нить записать к примеру.
+4
spiritedflow, #
Жесткая ссылка, это как банкоматы одного банка, через каждый ты можешь посмотреть один и тот же счёт, положить и снять деньги с него.

Символическая ссылка, это табличка «банкомат через два квартала прямо, потом налево» и не важно, есть там банкомат на самом деле или уже давно убрали.
0
Alkop, #
Автор молодец! Но, все таки надо как-то проще если, статью назвали «Простое объяснение символических и жестких ссылок» :)
–1
hybridcattt, #
Ставьте точки в конце абзацев! Неприятно читать.
Статья написана как для бабушек :)
НЛО прилетело и опубликовало эту надпись здесь
0
bondario, #
Автор упустил важный ньюанс, необходимо подчеркнуть «область работы ссылок».
Жесткие — в пределах одной файловой системы, символические на разных.
+1
AlexanderYastrebov, #
Да ладно вам, зато сколько классных и коротких объяснений в комментариях, да про НТФС еще исторический экскурс.
0
Derailed, #
Не нравится мне что-то преобладающая в комментариях критика. Статья хорошая. Я уже лет 10 как использую Linux и FreeBSD, но довольно редко, от случая к случаю — по принципу поставил/настроил/забыл о существовании (в повседневной жизни использую Windows). Поэтому постоянно забываю nix-овые заморочки наподобие soft- и hardlinks. Статья напомнила мне о том, что это такое и снова прочистила мозги, за что автору респект (получите заслуженный плюсик, пожалуйста).
+1
xn__p2a, #
Объяснение хардлинков и симлинков для самых маленьких (в картинках):

Hardlinks Symlinks scheme
Hardlinks Symlinks table
0
xn__p2a, #
Материал рассчитан на новичков в системе Linux (думаю, для профи это весьма банальные вещи).
Нет, просто профи поймут, что объяснение это нифига не простое и не такое уж и понятное…

Статья хороша только тем, что вынесла эту тему на обсуждение. Т.е. комментарии к этому топику, по-моему, гораздо полезнее для понимания сути вопроса, чем исходная статья автора.
0
hammerzeit_halt, #
автору статьи следовало таки познакомиться с той девушкой, что задержала библиотечную книгу.
0
davinchi, #
Ужас блин.

Вы перепутали «файловый индекс» (inode) и «запись в директории» (dentry).

Inode на самом деле на диске один и он идентифицируется только по номеру (iget_locked). Может быть множество записей в разных каталогах одной FS для данного inode, однако они содержат только имя и номер inode, счётчик ссылок содержится в самом inode.

Ну а про «автоматическое удаление» вообще молчу. Включается магия и маг стирает файл? Никакой автоматики, кроме запрограммированной человеком, не бывает.

Read The Fucking Sources…
0
Kastrulya, #
полки, библиотеки — очень сложно, уж извините=)

2 любимейшие мои ссылки — это em на emacs и apt на aptitude
+1
amima, #
«Пусть есть полки «Строительные стандарты» и «Машиностроительные стандарты». Но как поступить, если у нас есть стандарт, относящийся к проектированию механосборочных цехов? Ведь этот стандарт может понадобиться и строителям и в машиностроении.»

Это, видимо, должен был быть наглядный и понятный всем простой пример из жизни? :)))

Мне даже словосочетание «проектированию механосборочных цехов» не прочитать без небольшого скрипа, не говоря уже об осознании факта, что стандарт проектирования механосборочных цехов может относиться как к строителям, так и в машиностроении.

Проще, проще надо: ну там про еду примеры, про секс :). Это шутка конечно, но все-таки Ваши примеры — это абзац полный, караул!
0
nps, #
Пока все здесь, подскажите пожалуйста — как научить линукс ссылкам из винды?
Ведь файл .url — простой текстовый файлик с содержанием [InternetShortcut] URL=… — так может есть способ его прикрутить к браузеру?
И возможно ли Наутилус ссылки .lnk научить распозновать?
0
xn__p2a, #
И возможно ли Наутилус ссылки .lnk научить распозновать?
А заодно реализовать в Ubuntu критическую уязвимость LNK-файлов, что бы уж совсем совместимо с Windows было.
0
nps, #
Ах, так тем более надо! А то в убунте без вирусов скучно.
0
nsinreal, #
А почему б и нет собственно? Давненько на вирусах линукса не было
0
nimbos, #
Спасибо. Хорошая статья. Всё доступно написано.
0
skim1776, #
спасибо за статью, очень полезно и интересно. все понятно, нагляднее некуда

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