Основы Linux от основателя Gentoo. Часть 1 (3

Ссылка сама по себе — это цепочка символов, которая указывает/перенаправляет на объект, реально или физически существующий. Нужно различать постоянные (фиксированные, жёсткие — хардлинки) и гибкие (временные, символьные — симлинки) ссылки. Первые — когда, файл указывает на файл. Во втором случае — а это как раз наш — виртуальная папка указывает на целевую. Кроме всего, есть ещё и связующие ссылки, которые по сути являются теми же прямыми, но соединяют не файлы, а, используя различные переходы, папки и директории. При этом все папки остаются на прежних местах. Подробнее о типах ссылок в NTFS-системе — в конце статьи.

загляните внутрь папки Documents and Settings: ничего не замечаете?

А в Windows 10 этой папки нет? Вскроем скрытые файлы и папки:

Обратите внимание на Cвойства папки. Если вы не проводили дополнительный операций с разрешениями для папок и файлов, папку Documents and Setting вы вообще не сможете открыть. И всё по той же причине: её просто не существует, но «старым» службам и программам она необходима по определению. Так, Windows сохранила в своё время за пользователями право использовать устаревшие, но привычные (и, тем более, оплаченные по лицензии) программы. Особенно это касается пакета Microsoft Office. А та, как вы уже поняли, без папки обойтись не могла. Кстати, в этих фактах и кроется небольшая для первооткрывающих ссылки загадка: создаются они в основном для системных нужд. Вообще, все символьные ссылки в Windows делятся на две условные категории: системные связи и связи конечного пользователя. При этом по умолчанию символьные ссылки система для нас с вами не создаёт.

Символические ссылки используются в Linux для управления файлами и их сопоставления.

В этом руководстве вы узнаете, как использовать команду ln для создания символических ссылок в Linux.

Команда Ln

Команда Ln для создания символических ссылок

Чтобы использовать команду ln, откройте окно терминала и введите команду в следующем формате:

ln [-sf] [source] [destination]

По умолчанию команда ln создает hard link (жесткая ссылка).
Используйте параметр -s, чтобы создать символическую ссылку, она же soft link.
Параметр -f заставит команду перезаписать уже существующий файл.
Source – это файл или каталог, на который делается ссылка.
Destination – это место для сохранения ссылки – если это поле не заполнено, символическая ссылка сохраняется в текущем рабочем каталоге.

Например, создайте символическую ссылку с помощью:

ln -s test_file.txt link_file.txt

Это создает символическую ссылку link file.text, которая указывает на testfile.txt.

Чтобы проверить, создана ли символическая ссылка, используйте команду ls:

ls -l link_file.txt

ls -l link_file.txt

Создать символическую ссылку на каталог Linux

Символическая ссылка может относиться к каталогу. Чтобы создать символическую ссылку на каталог в Linux:

ln -s /mnt/external_drive/stock_photos ~/stock_photos

В этом примере создается символическая ссылка с именем stock_photos в домашнем каталоге ~ /. Ссылка относится к каталогу stock_photos на внешнем диске external_drive.

ln -s /mnt/external_drive/stock_photos ~/stock_photos

Примечание. Если система подключена к другому компьютеру, например к корпоративной сети или удаленному серверу, символические ссылки могут быть связаны с ресурсами в этих удаленных системах.

Принудительно перезаписать символические ссылки

Вы можете получить сообщение об ошибке, как показано на изображении ниже:

File exists

Сообщение об ошибке означает, что в месте назначения уже есть файл с именем link_file.txt. Используйте параметр -f, чтобы система перезаписывала целевую ссылку:

ln -sf test_file.txt link_file.txt

ln -sf test_file.txt link_file.txt

Примечание. Использование опции -f навсегда удалит существующий файл.

Удаление ссылок

Если исходный файл будет перемещен, удален или станет недоступным (например, сервер отключится), ссылку нельзя будет использовать. Чтобы удалить символическую ссылку, используйте команду rm (remove) или unlink:

rm link_file.txt
unlink link_file.txt

No such file

Soft Links против Hard Links

Команду ln можно использовать для создания двух разных типов ссылок:

Hard Links (жесткие ссылки)
Soft Links (символические или мягкие ссылки)

Символические ссылки (Soft Links)

Символическая ссылка, иногда называемая мягкой ссылкой или soft link, указывает на расположение или путь к исходному файлу. Она работает как гиперссылка в Интернете.

Вот несколько важных аспектов символической ссылки:

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

Жесткие ссылки (Hard Links)

Когда файл хранится на жестком диске, происходит несколько вещей:

Данные физически записываются на диск.
Создается справочный файл, называемый индексом, который указывает на расположение данных.
Имя файла создается для ссылки на данные inode.

Жесткая ссылка работает путем создания другого имени файла, которое ссылается на данные inode исходного файла. На практике это похоже на создание копии файла.

Вот несколько важных аспектов жестких ссылок:

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

Рекомендуем

Жесткие и символические ссылки давно знакомы и активно используются Linux-администраторами, в то время как их Windows коллеги используют их гораздо реже, а некоторые вообще не знают о такой возможности. Тем не менее такая возможность в Windows существует и позволяет значительно упростить некоторые сценарии работы с папками и файлами. В данной статье мы рассмотрим все виды ссылок, доступные в среде ОС Windows, а также разные способы работы с ними, начиная от командной строки и заканчивая PowerShell.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Жесткие ссылки (HardLink)

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

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

Жесткая ссылка может существовать только в пределах логического тома, поддерживается файловыми системами NTFS и ReFS начиная со сборки 19536.

Для создания жесткой ссылки можно воспользоваться утилитой mklink:

Где ключ /H предписывает создать именно жесткую ссылку, далее следует путь к новому файлу и целевому файлу, на который мы делаем ссылку. Путь можно указывать как абсолютные, так и относительные, в имени создаваемого файла не забывайте указывать расширение.

Ссылки можно создавать и при помощи PowerShell, для этого воспользуйтесь командой:

Команда другая, но принцип тот же самый: -ItemType – тип создаваемой ссылки, в нашем случае жесткая ссылка, -Path – путь к создаваемому файлу ссылки, -Target – файл на который мы делаем ссылку.

Можно ли сделать жесткую ссылку на директорию? Нет, только на файлы.

Вроде бы все понятно, но если внимательный читатель заглянет в свойства папки с жесткой ссылкой, то он увидит, что ее размер равен исходному файлу, если сделаем в ней еще одну жесткую ссылку – двум исходным файлам. Как так? Не стоит переживать, все нормально. Для операционной системы жесткая ссылка ничем не отличается от обычного файла и при подсчете свободного места учитывается размер каждой ссылки, но на самом деле на диске хранится единственная копия. В этом можно убедиться, если одновременно с созданием жестких ссылок контролировать свободное место на диске.

При желании мы можем провернуть даже такой фокус:

Какой вывод можно сделать из того, что мы увидели и где нам могут пригодиться жесткие ссылки? Прежде всего для предоставления пользователям доступа к объемным архивам, образам или инсталляционным пакетам. Скажем у вас есть файловый сервер и несколько отделов, каждому из которых нужно предоставить доступ к одному и тому же большому файлу. При этом вы можете не бояться, что кто-то удалит файл, он удалит его только у себя в директории, для остальных пользователей он останется доступен.

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

Точки соединения (Junction)

Очень старая технология, поддерживаемая еще начиная с Windows 2000, позволяет сделать один из каталогов псевдонимом другого каталога. Чем-то напоминает символические ссылки, но в крайне упрощенном варианте. В качестве цели можно использовать только локальные папки, но при этом нет ограничения по размещению их на одном томе. Т.е. целевая папка может находиться на диске C:, а точка соединения для нее на диске D: и все будет работать. Точки соединения поддерживаются файловыми системами NTFS и ReFS.

Для создания точки соединения можно использовать mklink:

Ключ /J указывает на создание точки соединения, далее следует папка каталога-псевдонима и папка целевого каталога. При любом изменении целевого каталога (перемещение, переименование, удаление) точка соединения перестает работать.

Обратите внимание, что данная папка в проводнике отображается как ярлык, а выводе команды dir как точка соединения.

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

Зачем сейчас нужны точки соединения? После появления в NT 6.0 настоящих символических ссылок не нужны, но вы можете встретиться с ними как в устаревших системах, так и в современных, где они могут присутствовать в виде наследия. Поэтому знать о них и уметь с ними работать современному администратору надо.

Символические ссылки (SymbolicLink)

Пожалуй, самый популярный вид связи, позволяет создавать множество псевдонимов для файлов или каталогов размещая их на любых поддерживаемых локальных файловых системах. В качестве цели могут быть использованы как локальные, так и сетевые объекты. При создании символической ссылки можно использовать как абсолютные, так и относительные пути. Но в последнем случае вы не можете перемещать ссылку – она перестанет работать. Символические ссылки поддерживаются начиная с NT 6.0 (Vista и Server 2008) и работают с файловыми системами NTFS и ReFS.

Для создания символических ссылок можно использовать mklink, без параметров она создает симлинк для файла:

При создании ссылки не забываем указать расширения для файла. Как и в случае с точкой соединения символическая ссылка отображается в виде ярлыка и обозначается в выводе команды dir:

Для создания символической ссылки на директорию добавьте ключ /D:

В PowerShell все проще, тип объекта будет определен автоматически:

Если в качестве цели указан файл – будет создана ссылка на файл, каталог – ссылка на каталог.

При переименовании, перемещении или удалении исходного файла или каталога все символические ссылки работать перестанут:

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

Причиной написания была эта статья Ссылки в Windows, символические и не только. Ее и можно почитать для ознакомление с тем, что такое жёсткие и символические ссылки в ntfs.
Я же продолжу и поделюсь некоторыми фактами о не очевидном поведении этих ссылок.

Сразу сделаю замечание. Если с жёсткими ссылками (Hard Links) неоднозначность вроде не наблюдается, то с мягкими или символическими ссылками есть путаница. Так вот я далее буду говорить о тех символических ссылках которые делаются программой Junction ( а также Alax.Info NTFS Links, Link Shell Extension и т.п.)
Подопытными программами были: Total Commander, Far, Frigate3, Servant Salamander, WinDirStat и Explorer в Windows XP.

Рекурсия.

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

Поиск.

Создадим каталог
X:\000
В нем создадим файл text.txt и символическую ссылку 111 на этот же каталог X:\000
Вот что выдадут при поиске файла наши подопытные файл-менеджеры кроме Far-а
X:\000\text.txt
X:\000\111\text.txt
X:\000\111\111\text.txt
X:\000\111\111\111\text.txt
X:\000\111\111\111\111\text.txt
X:\000\111\111\111\111\111\text.txt
X:\000\111\111\111\111\111\111\text.txt
X:\000\111\111\111\111\111\111\111\text.txt
X:\000\111\111\111\111\111\111\111\111\text.txt
X:\000\111\111\111\111\111\111\111\111\111\text.txt
X:\000\111\111\111\111\111\111\111\111\111\111\text.txt
X:\000\111\111\111\111\111\111\111\111\111\111\111\text.txt
X:\000\111\111\111\111\111\111\111\111\111\111\111\111\text.txt
X:\000\111\111\111\111\111\111\111\111\111\111\111\111\111\text.txt
X:\000\111\111\111\111\111\111\111\111\111\111\111\111\111\111\text.txt
X:\000\111\111\111\111\111\111\111\111\111\111\111\111\111\111\111\text.txt

Радует что рекурсия прервалась так рано. Но все равно такое поведение неправильно и может привести к ошибкам. Тут мы нашли один и тот же файл 16 раз. Многие программы для поиска дубликатов предложат удалить этот файл, как дубликат. Хотя на самом деле файл вполне уникален.
А вот Far, оказывается, при поиске вообще не переходит по символическим ссылкам.

Размер каталога

Такое поведение приводит к интересным эффектам при определении размера каталога. Можно сделать так, что этот размер окажется во много раз больше размера диска. Например на моем ноутбуке есть папка размером 300 Тб. Такой же фокус с размерами можно сделать используя жёсткие ссылки.

Среди подопытных программ правильно определили размер только WinDirStat и Explorer.
С эксплорером все понятно — он и реализация символических ссылок в windows детище одной и той же фирмы и было бы странно если они неправильно использовали свой же механизм ссылок. А вот WinDirStat так хорошо знаком со ссылками, наверное потому, что родом из Linux.

Копирование символических ссылок

При копировании ссылок подопытные файл-менеджеры вели себя по разному.
* Far — копировал символические ссылки как ссылки. Т.е. делал копию ссылки и не ее содержимого.
* Explorer на каждую ссылку задавал вопрос — копировать ее как каталог или как ссылку. Но я подозреваю что такое умное поведение ему придала установленная утилита Alax.Info NTFS Links. Проверить как ведет себя Explorer на windows xp без всяких расширений я не смог, а на windows 2000 explorer ведет при копировании себя как far.
* Все остальные подопытные копировали ссылки как каталоги.
При копировании ссылок нужно понимать, что это такое. Если ссылки копировать как файлы, то я например не смогу скопировать свою папочку «ИНТЕРНЕТ» в ближайшее время. Если же копировать ссылки как ссылки, то может оказаться, что скопированный на другой hdd в фаре каталог с фильмами у друга не откроется, так как внутри были символьные ссылки. А то куда они ссылались осталось на другом hdd. В общем при копировании наиболее правильно ведет себя Explorer в установленным правильным расширением.

Тут я решил проверить, а поддерживают ли архиваторы символические ссылки. Оказалось что нет. Все архиваторы из моей коллекции (в том числе 7Z, winrar ) не сохраняют символические ссылки. К сожалению в моей коллекции не оказалось портированных архиваторов вроде tar-а. Надеюсь, что программы из линукса опять помогут.

Что касается жёстких ссылок на файл, то все программы копируют, архивируют их как файлы, не распознавая ссылка это или нет. В принципе, это ожидаемо.

Удаление символических ссылок.

При удалении символических ссылок отличились Frigate3 и Servant Salamander. Они не только удалили ссылку, но и заботливо очистили содержимое каталога на который она ссылалась. Остальные подопытные удалили только ссылку.

Параноикам.

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

Выводы.

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

ЗЫ. Оказывается не хватает кармы, что бы писать в тематический блог. Ну да ладно. Может и тут кому полезно будет.

UPD: Эксперименты проводились в Microsoft Windows XP Home Edition 32bit SP3
Total Commander 7.04a
Far 1.70
Servant Salamander 2.0
WinDirStat 1.1.2.80 (Unicode)
Frigate 3.21.2.71
Explorer 6.00.2900.5512

Учел замечание Busla и поменял перевод Symbolic link на более распространенный вариант.

UPD2:
Дабы еще раз уточнить о чем речь и убрать разногласия в терминологии посеянные с легкой руки MS.
Полистав msdn я так понял, что в конце концов в MS пришли к единому мнению. Вроде как. И в Windows Vista сделали некие symbolic link которые создаются функцией CreateSymbolicLink .
А те символьные == символические == мягкие ссылки которые были (и есть) в ранних версиях Windows (2000,XP) являются некими reparse point. И создаются примерно так:
memset(reparseInfo, 0, sizeof(*reparseInfo));
reparseInfo->ReparseTag = IO_REPARSE_TAG_MOUNT_POINT;
reparseInfo->ReparseTargetLength =
_tcslen(targetNativeFileName) * sizeof(WCHAR);
reparseInfo->ReparseTargetMaximumLength =
reparseInfo->ReparseTargetLength + sizeof(WCHAR);
_tcscpy(reparseInfo->ReparseTarget, targetNativeFileName);
reparseInfo->ReparseDataLength = reparseInfo->ReparseTargetLength + 12;

DeviceIoControl(
hFile,
FSCTL_SET_REPARSE_POINT,
reparseInfo,
reparseInfo->ReparseDataLength + REPARSE_MOUNTPOINT_HEADER_SIZE,
NULL,
0,
&returnedLength,
NULL);

Так вот, поскольку у меня не виста, речь идет о reparse point. Хотя я предполагаю, что и symbolic link тоже преподнесут сюрприз неоднозначным поведением в разных программах. Ибо проблема в основном не в ссылках, а в том что некоторые программисты про них забывают.

Чем отличаются символьные ссылки от стандартных ярлыков?

Да, на первый взгляд ничем. По крайней мере, функции очень похожи. Но, присмотревшись, разницу можно увидеть и обычному пользователю. Начать можно с того, что символьная ссылка является неким указателем, работающем на уровне файловой структуры. Ярлык — порождение конкретного процесса. То бишь Проводника (он же explorer.exe). Таким образом ярлык — реально существующий и занимающий конкретное пространство файл, а символьной ссылки как таковой не существует. Это типа такой «призрак», системная голограмма, артефакт (он всегда весит 0 байт). В этом легко убедиться, создав ссылку и ярлык для одного объекта и посмотрев их Свойства.

Далее. Ярлык — файл, содержащий в себе конкретный путь от точки А в точку Б. Смысл его работы прост — дважды щёлкнули и перенеслись в нужном направлении. Всё: ярлык «появился» и «исчез» в ожидании следующего вызова. Символьная ссылка живёт постоянно и начинает работу вместе с включением системы. Так, щёлкнув по ярлыку, тот переносит вас к конкретному файлу или папке. Щёлкая по одноимённой символьной ссылке, создаётся впечатление, что в папке уже существует целый набор файлов. В этом (в том числе) вы можете убедиться, используя командную консоль: добраться до нужной папки вы можете, «зарядив» ссылку. В консоли такая операция с ярлыком не прокатит.

Таким образом, в отличии симлинка от обычного ярлыка и кроется её основное предназначение: Windows относится к симлинку как к настоящей папке. Т.е. разницы между ними нет. Одна и та же папка может находится сразу в нескольких местах. Представьте, что у вас есть программа, файлы которой ОБЯЗАТЕЛЬНО должны находиться по адресу C:\Program Files. Только системный диск забит и места на диске С уже нет. А вот другой диск или том под буквой, например, D полупуст. Вам нужно лишь перетащить вашу программу на диск D, создав попутно папку типа D:\Программа, создав в папке C:\Program Files симлинк на D:\Программа. И, если в вашем арсенале есть такие инструменты как виртуальный хранилища данных на манер like Dropbox, Google Drive, Яндекс.Диск или OneDrive, пространство рабочей зоны Windows можно серьёзно увеличить.

Создавая ссылки для Windows

В том виде, как вы их знаете, ссылки в Windows создаются в момент установки, что забирает львиную долю процесса инсталляции системы. Однако в числе инструментов из числа служебных утилит есть та, с помощью которой ссылки можно создавать самостоятельно. Знакомьтесь — mklink. В консоли cmd от имени администратора можно найти по утилите справку:

Давайте на секунду остановимся. Если вы наткнулись на статью случайно, вероятно, что и пояснение по используемым флагам /D и /J из справки утилиты не сильно разъяснит ситуацию (конкретно, разницу между этими флагами команды). И, опять же, умение правильно создать символьную ссылку или указующее соединение из mklink зависит от того, верно ли вы понимаете разницу в объясняемых справкой пунктах о /D (символьной ссылке), /J (соединениях каталогов) и /H (жёсткой ссылке). Об этом — в конце статьи.

Итак, создавать «собственные папки» просто. Например, мне нужно заставить появиться некую папку Директория на диске С, которая (на самом деле) является реально существующей у меня папкой по адресу D:\hacking\Python. Так и запишем:

Если название папки содержит несколько слов с пробелами, поместите весь путь (включая имя диска) целиком в команде в кавычки . Далее, немного усложним задачу, для чего создадим папку, создадим в ней файл, добавим для всего этого символическую ссылку, в окончание её же и удалим. Вот команды, а вы проверьте после ввода каждой из них, что происходит на диске С: с помощью проводника.

Как создавать и удалять симлинки

Работы с символьными ссылками в Windows ведутся из командной строки.

Синтаксис

mklink <имя создаваемого симлинка> <на что ведет симлинк>

Симлинк на файл

* в данном примере на рабочем столе пользователя dmosk будет создан симлинк на файл cmd.exe.

Симлинк на директорию

Для создания ссылки на папку доступен также ключ /J. Созданная таким образом ссылка будет по некоторым особенностям напоминать жесткую ссылку.

Удалить симлинк

В Windows его можно удалить в проводнике, как обычный файл или папку.

Разрешить симлинки в Windows

Если при попытке перейти по символьной ссылке мы получим ошибку «Символическая ссылка не может быть загружена, так как ее тип отключен», открываем командную строку от администратора и вводим команду:

Если это не помогло, пробуем создать симлинк с ключом /J.

Создание ссылок и удаление файлов

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

Мы уже упоминали термин «ссылка», когда рассказывали о взаимоотношениях между директориями (их именами) и инодами (индексным номерами, лежащими в основе файловой системы, которых мы не замечаем). Вообще в Linux существует два типа ссылок. Тип, о котором мы уже говорили ранее, называется «жесткие ссылки». Каждый инод может иметь произвольное число жестких ссылок. Когда уничтожается последняя жесткая ссылка, и не одна программа не держит файл открытым, то Linux автоматически удаляет его. Новые жесткие ссылки можно создать воспользовавшись командой ln:

Как видите, жесткие ссылки работают на уровне инодов, для указания конкретного файла. В Linux системах, для жестких ссылок есть несколько ограничений. В частности, можно создавать жесткие ссылки только на файлы, не на директории. Да-да, именно так; хотя “.” и “..” являются созданными системой жесткими ссылками на директории, вам (даже от имени пользователя «root») не разрешается создавать любые свои собственные. Второе ограничение жестких ссылок состоит в том, что нельзя связать ими несколько файловых систем. Это значит, что у вас не получится создать жесткую ссылку с /usr/bin/bash на /bin/bash и если ваши директории / и /usr находятся в разных файловых системах (разделах — прим. пер.).

Символьные ссылки

В практике, символьные ссылки (или символические, иногда «симлинки» — от англ.) используются гораздо чаще, чем жесткие. Симлинки — это файлы особого типа, которые ссылаются на другие файлы по имени, а не прямо по номеру инода. Они не спасают файлы от удаления; если файл, на который указывает ссылка, исчезает, то симлинк перестает работать, ломается.

Символические ссылки можно создать передав для ln опцию -s.

В выводе ls -l символьные ссылки можно отличить тремя способами. Во-первых, обратите внимание на символ l в первой колонке. Во-вторых, размер символической ссылки равен количеству символов в ней (secondlink в нашем случае). В-третьих, последняя колонка в выводе показывает куда ведет ссылка с помощью интуитивного обозначения “->”.

Симлинки детально

Символические ссылки в целом более гибкие, чем жесткие. Вы можете создавать символьные ссылки на любой объект файловой системы, включая директории. И благодаря тому, что их реализация основана на путях (не инодах), можно совершенно свободно создать символьную ссылку указывающую на объект другой файловой системы. Однако, сей факт также делает их сложными в понимании.

Предположим, что мы хотим создать ссылку в /tmp, которая указывает на /usr/local/bin. Нам следует набрать:

Как вы видите, обе символические ссылки указывают на одну директорию. Однако, если наша вторая символьная ссылка когда-нибудь будет перемещена в другую директорию, то она может «поломаться» из-за относительности пути:


 $ mkdir mynewdir
 $ mv bin2 mynewdir
 $ cd mynewdir
 $ cd bin2
 bash: cd: bin2: No such file or directory

Потому, что директории /tmp/usr/local/bin не существует, мы больше не можем переместиться в bin2; другими словами, bin2 сейчас сломана.

По этой причине, избегать создания ссылок с относительной информацией о пути, иногда будет хорошей идеей. Тем не менее, существует множество случаев, где относительные символические ссылки крайне удобны. Рассмотрим пример в котором мы хотим создать альтернативное имя для программы в /usr/bin:

От имени суперпользователя мы хотим короткий синоним для keychain, такой, как kc. В этом примере у нас есть root-доступ, о чем свидетельствует измененное на “#” приветствие bash. Нам нужен root-доступ потому, что обычные пользователи не имеют прав создавать файлы в /usr/bin. От имени суперпользователя мы можем создать альтернативное имя для keychain следующим образом:

В этом примере мы создали символьную ссылку под названием kc, которая указывает на файл /usr/bin/keychain.

Пока это решение будет работать, но создаст проблему, если мы решим переместить оба файла, /usr/bin/keychain и /usr/bin/kc в /usr/local/bin:

Поскольку мы использовали абсолютный путь для символической ссылки kc, то она все еще ссылается на /usr/bin/keychain, которого не существует с тех пор как мы переместили /usr/bin/keychain в /usr/local/bin.

Это привело к тому, что симлинк kc сейчас не работает. Как относительные, так и абсолютные пути в символьных ссылках имеют свои достоинства, и, в зависимости от вашей задачи, нужно использовать соответствующий тип пути. Часто, и относительный, и абсолютный путь, будут работать одинаково хорошо. Пример ниже будет работать, даже после перемещения обоих файлов:

Теперь, мы можем запустить программу keychain набрав /usr/local/bin/kc. /usr/local/bin/kc указывает на программу keychain в той же директории, где находится kc.

Итак, мы знаем как использовать cp, mv и ln, настало время узнать о том, как можно удалять объекты из файловой системы. Обычно это делается с помощью команды rm. Чтобы удалить файлы, просто укажите их в командной строке:


 $ rm file1 file2
 $ ls -l file1 file2
 ls: file1: No such file or directory
 ls: file2: No such file or directory

Имейте ввиду, что под Linux, однажды удаленный файл, обычно исчезает на века. Поэтому многие начинающие системные администраторы используют опцию -i, когда удаляют файлы. Опция -i сообщает rm удалять файлы в интерактивном режиме — это значит спрашивать перед удалением любого файла. Например:

$ rm -i file1 file2
 rm: remove regular empty file `file1'? y
 rm: remove regular empty file `file2'? y

В примере выше команда rm запрашивает подтверждение на удаление каждого из указанных файлов. В случае согласия, я должен был вводить «y» и нажать enter, дважды. Если бы я ввел «n», то файл бы остался цел. Или, если я сделал что-нибудь не так, я мог бы нажать Control-C и сбросить выполнение команды rm -i целиком — всяко до того, как это могло нанести какой-нибудь ущерб моей системе.

rmdir

Для удаления директорий у вас имеется два варианта. Вы можете удалить все объекты внутри директории и затем воспользоваться rmdir для удаления самой директории:

Этот метод широко известен под названием «способ удаления директорий для лохов». Все реальные пацаны и админы-гуру съевшие ~~пользователя~~ собаку на этом деле, используют гораздо более удобную команду rm -rf, описанную далее.

Самый лучший способ удалить директорию состоит в использовании опций «рекурсивного принуждения» (recursive force) команды rm, чтобы приказать ей удалять указанную директорию, также как и объекты содержащиеся внутри:

Обычно, rm -rf является наиболее предпочтительным методом для удаления древа директорий. Будьте очень осторожны, когда пользуетесь rm -rf, так как ее мощь может быть использована по обе стороны: добра и зла. =)

Точки стыка (жёсткие связи), соединения и символические ссылки файловой системы NTFS

Итак, в чём основные отличия связующих ссылок?

Жёсткая ссылка (hard link) — это файл, представляющий другой файл, находящийся на том же томе без дублирования его свойств. Жёстких ссылок на один файл может быть создано несколько, но на файл, находящийся в другом разделе (а тем более диске), жёсткую ссылку не поставить. Более того, жёсткие ссылки работают только с файлами — никаких директорий. Преимуществом жёсткой ссылки является тот факт, что, являясь копией настоящего, она не требует дополнительного пространства на диске. Так, если вы создали 5 ссылок на 1 файл весом 100 Мб, общий объём занимаемого места так и останется 100 Мб (а не 600 Мб). Любую из этих ссылок можно удалить, остальные и сам файл-оригинал останутся. А все изменения в файле отображаются и в ссылках.

Соединения для каталога — это ссылки на целевую директорию/папку. Соединения уже видят не только собственные тома, но и соседние разделы. Но, опять же, лишь в пределах локальной машины. Также не требуют свободного места, лишь указывая на оригинальную директорию. Если ту удалить или переместить, связи сломаются, и ссылки работать не будут. Помните историю про Documents and Settings? Это и есть пример такого соединения.

Символические ссылки появились с Windows Vista. Они представляют собой объект файловой системы, указывающий на другой объект. Это «супер-продвинутый» ярлык. И такие «ярлыки» могут указывать на любые файлы и папки в пределах локальной сети (с установленными Windows Vista и позднее). Объёмы жёсткого диска также не используются. Кроме того, связь по такой ссылке может осуществляться в виде абсолютного (полного) маршрута и относительного пути к целевой папке/файлу. Первый вариант — это всем знакомый по проводнику тип тропинки Диск:\Каталог\Подкаталог\Файл. В относительной ссылке пути к целевой директории могут перемежёвываться. Но объединяет их одно — система и программы воспринимает ссылки и цель как одно и тоже. При редактировании ссылок и цели ссылки наследуют свойства предыдущего варианта связей NTFS-системы.

Отличия между типами связей можно представить в таком виде:

Закончить можно ещё одним фактом: создание связи между файлами или каталогами в NTFS ни в коем случае не подразумевает копирование или резервирование целевых файлов или папок. И Windows не следит за состоянием цепочки: удаляете цель — получаете ошибку.

Ну, вот такая в целом ситуация с типами внутренних связей Windows. Успехов.

А зачем это надо-то?

Да, казалось бы, в том варианте как описывается, разницы между созданием обычного ярлыка для файла или папки нет. Но это лишь на первый взгляд. Ну, представьте себе, что купленная только что игра требует установиться в корневую C:\Games (как обычно), требуя при том свободного места на диске С этак Гбайт 30. И при этом карта системного диска С выглядит примерно так:

справится с задачей в два счёта. И оп: игра-то думает, что её установили в нужную папку. А это не так, на самом деле. Какие ещё варианты? Я не особо игрок, но для меня, обладателя огромного количества виртуальных машин, которые занимают немало пространства, в такой ситуации тоже есть свои плюсы как решить проблему нехватки пространства для кучи виртуальных Windows.

Кроме того, создание ссылки подразумевает возможность быстрого к ней обращения: фактически вы создаёт новый путь. А он может быть максимально коротким. И тут в дело вступает возможность быстрого доступа из поисковой строки. Например, на одном из томов хранятся памятные фотографии, причём доступ к ним ограничен, а путь бесконечно долог для проводника. Создадим ссылку на манер:

А теперь набираем WIN + R, вводим и работаем как хотим:

Ссылки Windows из mklink

Linux и FreeBSD

Создание

ln -s <на какой существующий объект будет вести> <создаваемый симлинк>

В системах на базе Linux (например, Ubuntu или CentOS) и FreeBSD симлинк для каталога и файла создаются одинаково:

Удаление

Об авторах

Daniel Robbins

Chris Houser

Крис Хаусер был сторонником UNIX c 1994 года, когда присоединился к команде администраторов университета Тэйлора (Индиана, США), где получил степень бакалавра в компьютерных науках и математике. После он работал во множестве областей, включая веб-приложения, редактирование видео, драйвера для UNIX и криптографическую защиту. В настоящий момент работает в Sentry Data Systems. Крис также сделал вклад во множество свободных проектов, таких как Gentoo Linux и Clojure, стал соавтором книги The Joy of Clojure.

Aron Griffis

Эйрон Гриффис живет на территории Бостона, где провел последнее десятилетие работая в Hewlett-Packard над такими проектами, как сетевые UNIX-драйвера для Tru64, сертификация безопасности Linux, Xen и KVM виртуализация, и самое последнее — платформа HP ePrint. В свободное от программирования время Эйрон предпочитает размыщлять над проблемами программирования катаясь на своем велосипеде, жонглируя битами, или болея за бостонскую профессиональную бейсбольную команду «Красные Носки».

Решение возможных проблем

При работе с симлинками мы можем сталкиваться с различными проблемами. Я рассмотрю те, с которыми приходилось сталкиваться мне.

ln: failed to create symbolic link … Function not implemented

При попытке создать симлинк мы можем получить ошибку Function not implemented, например:

ln: failed to create symbolic link ‘/etc/pve/nodes/pve/fullchain.pem’: Function not implemented

Причина: файловая система, на которой мы хотим создать файл не поддерживает симлинки. Посмотреть файловую систему подмонтированных разделов можно командой:

Решение: как правило, решения зависит от используемой файловой системы и ее драйвера. Но, обычно, решения у проблемы нет и нужно искать методы работы без использования символьных ссылок.

Основы Linux от основателя Gentoo. Часть 1 (3

Syntax

Parameters

Examples

Related links

Syntax

Parameters

Examples

Related links

СПРАВКА, или что такое ссылка для Windows?

Команда Ln для создания символических ссылок

Создать символическую ссылку на каталог Linux

Принудительно перезаписать символические ссылки

Удаление ссылок

Soft Links против Hard Links

Символические ссылки (Soft Links)

Жесткие ссылки (Hard Links)

Рекомендуем

Предыстория

Дополнительные материалы по теме

Софт

Утилиты от Microsoft

Windows >= Vista

Windows >= 2000

Расширения для Explorer

NTFS Links — дополнение для Total Commander

FAR

Junction Link Magic

Junction — консольная программа для создания Junction Points

Рекомендуем

Жесткие ссылки (HardLink)

Точки соединения (Junction)

Символические ссылки (SymbolicLink)

Рекурсия.

Поиск.

Размер каталога

Копирование символических ссылок

Удаление символических ссылок.

Параноикам.

Выводы.

Чем отличаются символьные ссылки от стандартных ярлыков?

Создавая ссылки для Windows

Как создавать и удалять симлинки

Синтаксис

Симлинк на файл

Симлинк на директорию

Удалить симлинк

Разрешить симлинки в Windows

Создание ссылок и удаление файлов

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

Символьные ссылки

Симлинки детально

rm

rmdir

Точки стыка (жёсткие связи), соединения и символические ссылки файловой системы NTFS

А зачем это надо-то?

Ссылки Windows из mklink

Linux и FreeBSD

Создание

Удаление

Об авторах

Daniel Robbins

Chris Houser

Aron Griffis

Решение возможных проблем

ln: failed to create symbolic link … Function not implemented

Похожее:

Оставьте комментарий Отменить ответ