Пользователь
0,0
рейтинг
21 июля 2010 в 22:27

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

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


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

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


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

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

image

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

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

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

cd                   # в домашний каталог<br>
mkdir -p standards/{civil,mechanical} # создать структуру необходимых каталогов<br>
cd standards/civil   # в каталог строительных стандартов<br>
touch document1.txt  # создаем новый файл со стандартом<br>
echo "some text" > document1.txt  # содержимое...<br>
<br>
man ln               # для выхода нажать "q"; это справка по "ln", почитайте<br>
cd ../mechanical/    # в каталог машиностроительных стандартов<br>
ln -s ../civil/document1.txt document1.txt    # создаем симв. ссылку <br>
                                              # с таким же именем<br>
ls -l                # посмотрим, что вышло<br>
pwd                  # где мы находимся<br>
file document1.txt   # что за файл "document.txt" в текущем каталоге?<br>
cat document1.txt    # просмотр исходного файла по ссылке<br>
echo "additional text" >> document1.txt   # редактирование файла по ссылке<br>
cat ../civil/document1.txt  # видно, что оригинал изменился<br>
rm -f ../civil/document1.txt   # удаление оригинального документа<br>
ls -l                # а ссылка осталась<br>
cat document1.txt    # ошибка, т.к. ссылка "висячая" (ссылается на<br>
                     # несуществующий файл)<br>
echo "new text" >> document1.txt   # запись в файл по ссылке;<br>
                                   # будет создан новый файл-оригинал -<br>
                                   # ~/standards/civil/document1.txt<br>
cat document1.txt    # переход по ссылке, видно что файл-оригинал существует<br>
<br>
<br>
cp document1.txt ../document1.txt  # копируем ссылку в каталог "standards"<br>
cd ../                             # переход в каталог "standards"<br>
ls -l                              # видно, что скопирован файл-оригинал<br>
file document1.txt                 # ...не ссылка, а настоящий файл<br>


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

Найдите легкий способ создания символических ссылок в вашей любимой оконной среде (например, с помощью drag-n-drop); создайте символические ссылки на рабочем столе для наиболее часто используемых приложений.

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


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

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

image

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

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

image

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

image

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

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

# в той же иерархии каталогов, что была создана в работе по симв. ссылкам<br>
# /home/joe/standards<br>
cd civil<br>
echo "123456" > myfile<br>
ls -i myfile                    # уникальный номер созданного файла<br>
ls -l myfile                    # число 1 указывает, что у файла одна жесткая<br>
                                # ссылка<br>
ln myfile ../mechanical/myfile  # создаем жесткую ссылку<br>
                                # пусть имена файлов будут одинаковые<br>
cd ../mechanical/<br>
ls -i myfile                    # уникальные номера совпадают<br>
ls -l myfile                    # видим, что у файла уже 2 жестких ссылки<br>
file myfile                     # при чем файловая система видет напрямую файл<br>
                                # а не ссылку (как при симв. ссылке)<br>
<br>
cp myfile ../myfile             # скопируем в каталог standards<br>
cd ../<br>
ls -il myfile                   # у скопированного файла уже другой уникальный<br>
                                # номер, и счетчик ссылок – 1, т.е. это новый<br>
                                # файл а не жесткая ссылка на созданный нами<br>
rm -f civil/myfile              # удалим созданный нами в самом начале файл<br>
cd mechanical/<br>
ls -il myfile                   # количество ссылок стало 1, но номер тот же<br>


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

Выводы

  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, но, как сказал бы доктор МакКой: «Я врач, а не художник» :)
Sam Protsenko @skb7
карма
33,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

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

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

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

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

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

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

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

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

          Создадим файл 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
      самое простое объяснение — если стереть файл то симфолическая ссылка перестанет работать, место на диске освободится, а жесткая ссылка продолжит работать, файл останется на месте, место на диске не изменится.
      • +1
        еще «сборщик мусора» сюда приписать — закончились ссылки на данные и только тогда данные будут удалены (чаще всего помечены как освободившиеся)
  • +29
    А что там понимать? Жесткая ссылка — это просто дополнительное имя файла, работает она в пределах одной физической файловой системы, при этом имя оригинала может меняться как угодно, его можно даже удалить, а жесткая ссылка останется, а символическая ссылка это просто ссылка на файл в пределах virtual file system и её аналогов, соответственно она не чувствительна к фс, на которой файл лежит, но чувствительна к его полному названию
    • +5
      У вас слишком маленькое и доступное объяснение.
    • +12
      Какое-то объяснение «для лохов». Ни одной формулы.
  • +6
    ntfs замечательно работает с ссылками.
    • –2
      Не спорю. Я лишь написал, что работа со ссылками в NTFS не так прозрачна, а именно — для этого требуются дополнительное ПО, не входящее в состав ОС, и не все программы реализованы корректно (как я могу судить по этой статье vpbar.habrahabr.ru/blog/51294/)
      • +1
        «а именно — для этого требуются дополнительное ПО»

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

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

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

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

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

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

                          Костыль

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

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

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

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

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

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

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

        Впрочем, закончу оффтоп в этом блоге. ;)
      • +1
        А fsutil на что?
      • 0
        А зачем вы судите по этой статье, если там в предисловии явно указано, что рассматривается только некоторый ограниченный функционал: «далее буду говорить о тех символических ссылках которые делаются программой Junction» и старая ОС.
        Почему бы не откпать статью про Win98 и на её основе делать выводы? ;)
    • +12
      > 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
        О, теперь всё встало на свои места. :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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