Третий отрывок из перевода первой части руководства. Предыдущие: первый
, второй
.
В этом отрывке рассмотрены жесткие и символические ссылки, а также разобрано удаление файлов и директорий с помощью команд rm и rmdir.
Товарищи, добрый день. Хотя эта тема и не самая популярная, но она мне очень много раз выручала, поэтому я не могу о ней не написать. Итак, что значит термин «символьная ссылка» я возьму из энциклопедии Wikipedia:
Символьная ссылка (также симлинк от англ. Symbolic link, символическая ссылка) — специальный файл в файловой системе, для которого не формируются никакие данные, кроме одной текстовой строки с указателем. Эта строка трактуется как путь к файлу, который должен быть открыт при попытке обратиться к данной ссылке (файлу). Символьная ссылка занимает ровно столько места в файловой системе, сколько требуется для записи её содержимого (нормальный файл занимает как минимум один блок раздела).
По своей сути же, симлинк — это ярлык, который позволяет системе думать, что это не ярлык, а настоящий файл (или папка). К примеру, частое применение символьной ссылок для папок — это установка игры на SSD, с последующем переносом файлов графики на жесткий диск, с целью экономия места на SSD и создание символьной ссылки до исходного места. Игра будет думать, что все файлы находятся в исходной папке. Так же символьные ссылки можно применять когда используются одинаковые файлы в нескольких каталогах, чтобы не вносить правки во все файлы, можно создать с одного файла символьные ссылки и вносить изменения один раз.
Создать символьную ссылку очень просто и сейчас я вам это докажу. Открываем командную строку
, нажимаем Win+R
, вводим cmd
и жмём ОК
. Хотя если вы собираетесь работать с системными файлами, может понадобиться командная строка с правами администратора.
Дальше нам нужно ввести команду для создания символьной ссылки, выглядит она следующем образом:
mklink /j "путь, где будет создана символьная ссылка" "путь, где находятся исходный файл или папка"
где /j
— атрибут создания соединения для каталога. Если вы создаете ссылку на файл, атрибут ставить не надо.
К примеру, если я хочу создать символьную ссылку на папку mklink
на локальном диске E
, как папку mk
на диске С
, мне нужно ввести следующую команду (и да, символьная ссылка может называться не так, как исходный файл (папка):
mklink /j "C:\mk" "E:\mklink"
В результате мы получим вот это.
Если же мы хотим создать символьную ссылку на файл, например на файл 1.txt
, хранящийся в корне диска E
. для использования в виде файла 2.txt
. скажем в папке mslink
на диске C
, команда будет выглядеть вот так:
mklink "C:\mslink\2.txt" "E:\1.txt"
А на выходе получим вот это.
Резюмируя скажу, что знание возможностей данной функции, открывает большие возможности. С помощью неё я выходил из нескольких ситуаций, когда не хватало свободного пространства, на моем старом SSD, позволяя быстро перенести игру из папки origin на другой диск. Но вариантов использования её гораздо больше, к примеру перенос кэша браузеров, о котором мы поговорим в одной из будущих статей.
Материал сайта geekteam.pro
Предыстория
В своём топике ” Впечатления от Яндекс. Субботника
” хабрачеловек absolvo
высказал удивление, что один из докладчиков не знал о том, что символьные ссылки есть и в Windows. Честно говоря, не знал этого и я, поэтому поинтересовался об этих ссылках в комментариях
.
Думаю, то, что удалось выяснить, может показаться кому-нибудь полезным.
Сразу оговорюсь, что под ссылками в Windows я понимаю ссылки в NTFS. В FAT механизмов ссылок, насколько мне известно, предусмотрено не было.
Ядро Windows поддерживает следующие виды ссылок:
- Hard Links — жёсткие ссылки, как в *nix. Доступны начиная с Windows NT4.
- Junction Points — аналог символических ссылок. Доступен начиная с Windows 2000 (NTFS 5).
- Symbolic Links — символьные ссылки. Доступны начиная с Windows Vista.
Если вы никогда не имели дела с символическими и жёсткими ссылками, но хотели бы узнать о них, советую прочитать отрывок из документации файлового менеджера FAR
, спасибо хабрачеловеку allemeine
. Там говорится только о Hard Links и Junction Points, но этого вполне достаточно. Symbolic Links действуют так же, как и Junction Points, с той разницей, что могут указывать на файлы (и реализованы в Windows по-другому).
Hard Links можно создавать только на файлы, Junction Points — только на директории, Symbolic Links — на файлы и директории. В дальнейшем под «жёсткими ссылками» подразумеваются Hard Links, под «символьными» — Junction Points и Symbolic Links.
Жёсткие ссылки действительны в пределах одного раздела, символьные — могут пересекать границы разделов. В связи с этим символьные ссылки могут поломаться, если структуру разделов поменять.
Не со всем, что поддерживается ядром, умеет нормально работать эксплорер. Будьте осторожны при использовании Junction Points в версиях Windows до Vista. При удалении Junction Point эксплорер может залезть внутрь директории, на которую ссылается Junction Point и поудалять там всё, а затем удалить Junction Point, хотя должен лишь удалить ссылку. Наверняка могут возникнуть проблемы и при перемещении или копировании Junction Point’ов.
Мне неизвестно, нормально ли в версиях Windows до Vista относятся к Junction Points стандартные утилиты типа rmdir.
Дополнительные материалы по теме
По словам хабрачеловека SamDark
, хорошее описание всех видов ссылок есть ещё в справке по NTFS Links (дополнению для Total Commander, см. ниже).
Софт
Утилиты от Microsoft
Windows >= Vista
В Windows Vista добавили команду mklink
для создания символьных и жёстких ссылок (спасибо за информацию хабрачеловеку metamorph
).
Windows >= 2000
fsutil hardlink create ссылка файл
Создаёт Hard Link на файл ( источник
).
linkd ссылка директория
Создаёт Junction Point на директорию ( источник
). Утилита входит в Microsoft Windows Resources Kit
.
Расширения для Explorer
NTFS Link
интегрируется в Explorer и добавляет во всплывающее меню, появляюшееся после перетаскивания правой кнопкой мыши, пункты «Create junction point» и «Create hard link». Кроме того, она перехватывает вызовы Explorer’а, обеспечивая нормальное перемещение/копирование/удаление созданных ссылок.
NTFS Links — дополнение для Total Commander
Страница программы
(за информацию спасибо хабрачеловеку SamDark
). Плагин может запускаться как отдельная программа, вне Total Commander’а.
FAR
Junction Link Magic
Junction — консольная программа для создания Junction Points
UPD
: обновил топик с учётом комментариев.
Жесткие и символические ссылки давно знакомы и активно используются Linux-администраторами, в то время как их Windows коллеги используют их гораздо реже, а некоторые вообще не знают о такой возможности. Тем не менее такая возможность в Windows существует и позволяет значительно упростить некоторые сценарии работы с папками и файлами. В данной статье мы рассмотрим все виды ссылок, доступные в среде ОС Windows, а также разные способы работы с ними, начиная от командной строки и заканчивая PowerShell.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik
. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Жесткие ссылки (HardLink)
Жесткие ссылки представляют собой дополнительную запись в файловой таблице раздела для существующего файла. Таким образом жесткая ссылка ничем не отличается от исходного файла, но файл при этом не копируется физически и остается на диске в единственном экземпляре. При изменении файла по любой из жестких ссылок, остальные обновляются автоматически (что логично, так как файл один).
Мы можем переименовывать, копировать, перемещать (в пределах логического тома) ссылки – размер занимаемого места при этом не изменится. При удалении ссылок файл продолжает существовать до тех пор, пока не будет удалена последняя жесткая ссылка на него. Фактически отличить, где находится оригинальный файл, а где жесткая ссылка невозможно, по сути, файл на разделе это и есть жесткая ссылка.
Жесткая ссылка может существовать только в пределах логического тома, поддерживается файловыми системами NTFS и ReFS начиная со сборки 19536.
Для создания жесткой ссылки можно воспользоваться утилитой mklink
:
mklink /H C:\Folder1\LinkFileName C:\Folder\FileName
Где ключ /H
предписывает создать именно жесткую ссылку, далее следует путь к новому файлу и целевому файлу, на который мы делаем ссылку. Путь можно указывать как абсолютные, так и относительные, в имени создаваемого файла не забывайте указывать расширение.
Ссылки можно создавать и при помощи PowerShell
, для этого воспользуйтесь командой:
New-Item -ItemType HardLink -Path C:\Folder1\LinkFileName -Target C:\Folder\FileName
Команда другая, но принцип тот же самый: -ItemType
– тип создаваемой ссылки, в нашем случае жесткая ссылка, -Path
– путь к создаваемому файлу ссылки, -Target
– файл на который мы делаем ссылку.
Можно ли сделать жесткую ссылку на директорию? Нет, только на файлы.
Вроде бы все понятно, но если внимательный читатель заглянет в свойства папки с жесткой ссылкой, то он увидит, что ее размер равен исходному файлу, если сделаем в ней еще одну жесткую ссылку – двум исходным файлам. Как так? Не стоит переживать, все нормально. Для операционной системы жесткая ссылка ничем не отличается от обычного файла и при подсчете свободного места учитывается размер каждой ссылки, но на самом деле на диске хранится единственная копия. В этом можно убедиться, если одновременно с созданием жестких ссылок контролировать свободное место на диске.
При желании мы можем провернуть даже такой фокус:
Какой вывод можно сделать из того, что мы увидели и где нам могут пригодиться жесткие ссылки? Прежде всего для предоставления пользователям доступа к объемным архивам, образам или инсталляционным пакетам. Скажем у вас есть файловый сервер и несколько отделов, каждому из которых нужно предоставить доступ к одному и тому же большому файлу. При этом вы можете не бояться, что кто-то удалит файл, он удалит его только у себя в директории, для остальных пользователей он останется доступен.
Но при этом надо очень внимательно относиться к вопросу одновременного редактирования файла, так как он существует в единственном экземпляре, но доступен по множеству ссылок в этом сценарии могут возникнуть самые разные коллизии.
Точки соединения (Junction)
Очень старая технология, поддерживаемая еще начиная с Windows 2000, позволяет сделать один из каталогов псевдонимом другого каталога. Чем-то напоминает символические ссылки, но в крайне упрощенном варианте. В качестве цели можно использовать только локальные папки, но при этом нет ограничения по размещению их на одном томе. Т.е. целевая папка может находиться на диске C:, а точка соединения для нее на диске D: и все будет работать. Точки соединения поддерживаются файловыми системами NTFS и ReFS.
Для создания точки соединения можно использовать mklink
:
mklink /J D:\LinkFolder C:\Folder
Ключ /J
указывает на создание точки соединения, далее следует папка каталога-псевдонима и папка целевого каталога. При любом изменении целевого каталога (перемещение, переименование, удаление) точка соединения перестает работать.
Обратите внимание, что данная папка в проводнике отображается как ярлык, а выводе команды dir
как точка соединения.
Это же действие в PowerShell
:
New-Item -ItemType Junction -Path D:\LinkFolder -Target C:\Folder
Комментировать здесь особо нечего, краткость не входит в число добродетелей PowerShell, но не оставляет места догадкам, все просто и понятно.
Зачем сейчас нужны точки соединения? После появления в NT 6.0 настоящих символических ссылок не нужны, но вы можете встретиться с ними как в устаревших системах, так и в современных, где они могут присутствовать в виде наследия. Поэтому знать о них и уметь с ними работать современному администратору надо.
Символические ссылки (SymbolicLink)
Пожалуй, самый популярный вид связи, позволяет создавать множество псевдонимов для файлов или каталогов размещая их на любых поддерживаемых локальных файловых системах. В качестве цели могут быть использованы как локальные, так и сетевые объекты. При создании символической ссылки можно использовать как абсолютные, так и относительные пути. Но в последнем случае вы не можете перемещать ссылку – она перестанет работать. Символические ссылки поддерживаются начиная с NT 6.0 (Vista и Server 2008) и работают с файловыми системами NTFS и ReFS.
Для создания символических ссылок можно использовать mklink
, без параметров она создает симлинк для файла:
mklink C:\Folder1\LinkFileName C:\Folder\FileName
При создании ссылки не забываем указать расширения для файла. Как и в случае с точкой соединения символическая ссылка отображается в виде ярлыка и обозначается в выводе команды dir
:
Для создания символической ссылки на директорию добавьте ключ /D
:
mklink /D D:\LinkFolder C:\Folder
В PowerShell
все проще, тип объекта будет определен автоматически:
New-Item -ItemType SymbolicLink -Path C:\Folder1\LinkFileName -Target C:\Folder\FileName
Если в качестве цели указан файл – будет создана ссылка на файл, каталог – ссылка на каталог.
При переименовании, перемещении или удалении исходного файла или каталога все символические ссылки работать перестанут:
При копировании символической ссылки за пределы локального тома будет скопирован исходный файл, даже если целевой том поддерживает работу со ссылками, но это не мешает создать новую ссылку на другом томе.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik
. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Причиной написания была эта статья Ссылки в 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 тоже преподнесут сюрприз неоднозначным поведением в разных программах. Ибо проблема в основном не в ссылках, а в том что некоторые программисты про них забывают.
Создание ссылок и удаление файлов
Жесткие ссылки
Мы уже упоминали термин «ссылка», когда рассказывали о взаимоотношениях между директориями (их именами) и инодами (индексным номерами, лежащими в основе файловой системы, которых мы не замечаем). Вообще в Linux существует два типа ссылок. Тип, о котором мы уже говорили ранее, называется «жесткие ссылки». Каждый инод может иметь произвольное число жестких ссылок. Когда уничтожается последняя жесткая ссылка, и не одна программа не держит файл открытым, то Linux автоматически удаляет его. Новые жесткие ссылки можно создать воспользовавшись командой ln:
$ cd /tmp
$ touch firstlink
$ ln firstlink secondlink
$ ls -i firstlink secondlink
15782 firstlink 15782 secondlink
Как видите, жесткие ссылки работают на уровне инодов, для указания конкретного файла. В Linux системах, для жестких ссылок есть несколько ограничений. В частности, можно создавать жесткие ссылки только на файлы, не на директории. Да-да, именно так; хотя “.” и “.” являются созданными системой жесткими ссылками на директории, вам (даже от имени пользователя «root») не разрешается создавать любые свои собственные. Второе ограничение жестких ссылок состоит в том, что нельзя связать ими несколько файловых систем. Это значит, что у вас не получится создать жесткую ссылку с /usr/bin/bash
на /bin/bash
и если ваши директории /
и /usr
находятся в разных файловых системах (разделах — прим. пер.).
Символьные ссылки
В практике, символьные ссылки (или символические, иногда «симлинки» — от англ.) используются гораздо чаще, чем жесткие. Симлинки — это файлы особого типа, которые ссылаются на другие файлы по имени, а не прямо по номеру инода. Они не спасают файлы от удаления; если файл, на который указывает ссылка, исчезает, то симлинк перестает работать, ломается.
Символические ссылки можно создать передав для ln опцию -s.
$ ln -s secondlink thirdlink
$ ls -l firstlink secondlink thirdlink
-rw-rw-r-- 2 agriffis agriffis 0 Dec 31 19:08 firstlink
-rw-rw-r-- 2 agriffis agriffis 0 Dec 31 19:08 secondlink
lrwxrwxrwx 1 agriffis agriffis 10 Dec 31 19:39 thirdlink -> secondlink В выводе ls -l символьные ссылки можно отличить тремя способами. Во-первых, обратите внимание на символ l в первой колонке. Во-вторых, размер символической ссылки равен количеству символов в ней ( secondlink
в нашем случае). В-третьих, последняя колонка в выводе показывает куда ведет ссылка с помощью интуитивного обозначения “->”.
Симлинки детально
Символические ссылки в целом более гибкие, чем жесткие. Вы можете создавать символьные ссылки на любой объект файловой системы, включая директории. И благодаря тому, что их реализация основана на путях (не инодах), можно совершенно свободно создать символьную ссылку указывающую на объект другой файловой системы. Однако, сей факт также делает их сложными в понимании.
Предположим, что мы хотим создать ссылку в /tmp
, которая указывает на /usr/local/bin
. Нам следует набрать:
$ ln -s /usr/local/bin bin1
$ ls -l bin1
lrwxrwxrwx 1 root root 14 Jan 1 15:42 bin1 -> /usr/local/binЛибо, альтернативный вариант:
$ ln -s ./usr/local/bin bin2
$ ls -l bin2
lrwxrwxrwx 1 root root 16 Jan 1 15:43 bin2 -> ./usr/local/binКак вы видите, обе символические ссылки указывают на одну директорию. Однако, если наша вторая символьная ссылка когда-нибудь будет перемещена в другую директорию, то она может «поломаться» из-за относительности пути:
$ ls -l bin2
lrwxrwxrwx 1 root root 16 Jan 1 15:43 bin2 -> ./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
:
# ls -l /usr/bin/keychain
-rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/bin/keychain От имени суперпользователя мы хотим короткий синоним для keychain
, такой, как kc
. В этом примере у нас есть root-доступ, о чем свидетельствует измененное на “#” приветствие bash. Нам нужен root-доступ потому, что обычные пользователи не имеют прав создавать файлы в /usr/bin
. От имени суперпользователя мы можем создать альтернативное имя для keychain
следующим образом:
# cd /usr/bin
# ln -s /usr/bin/keychain kc
# ls -l keychain
-rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/bin/keychain# ls -l kc
lrwxrwxrwx 1 root root 17 Mar 27 17:44 kc -> /usr/bin/keychain
В этом примере мы создали символьную ссылку под названием kc, которая указывает на файл /usr/bin/keychain
.
Пока это решение будет работать, но создаст проблему, если мы решим переместить оба файла, /usr/bin/keychain
и /usr/bin/kc
в /usr/local/bin
:
# mv /usr/bin/keychain /usr/bin/kc /usr/local/bin
# ls -l /usr/local/bin/keychain
-rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/local/bin/keychain# ls -l /usr/local/bin/kc
lrwxrwxrwx 1 root root 17 Mar 27 17:44 kc -> /usr/bin/keychain
Поскольку мы использовали абсолютный путь для символической ссылки kc
, то она все еще ссылается на /usr/bin/keychain
, которого не существует с тех пор как мы переместили /usr/bin/keychain
в /usr/local/bin
.
Это привело к тому, что симлинк kc сейчас не работает. Как относительные, так и абсолютные пути в символьных ссылках имеют свои достоинства, и, в зависимости от вашей задачи, нужно использовать соответствующий тип пути. Часто, и относительный, и абсолютный путь, будут работать одинаково хорошо. Пример ниже будет работать, даже после перемещения обоих файлов:
# cd /usr/bin
# ln -s keychain kc
# ls -l kc
lrwxrwxrwx 1 root root 8 Jan 5 12:40 kc -> keychain# mv keychain kc /usr/local/bin
# ls -l /usr/local/bin/keychain
-rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/local/bin/keychain
# ls -l /usr/local/bin/kc
lrwxrwxrwx 1 root root 17 Mar 27 17:44 kc -> keychain
Теперь, мы можем запустить программу keychain
набрав /usr/local/bin/kc
. /usr/local/bin/kc
указывает на программу keychain
в той же директории, где находится kc
.
rm
Итак, мы знаем как использовать cp, mv и ln, настало время узнать о том, как можно удалять объекты из файловой системы. Обычно это делается с помощью команды rm. Чтобы удалить файлы, просто укажите их в командной строке:
$ cd /tmp
$ touch file1 file2
$ ls -l file1 file2
-rw-r--r-- 1 root root 0 Jan 1 16:41 file1
-rw-r--r-- 1 root root 0 Jan 1 16:41 file2$ 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 целиком — всяко до того, как это могло нанести какой-нибудь ущерб моей системе.
alias rm="rm -i"
rmdir
Для удаления директорий у вас имеется два варианта. Вы можете удалить все объекты внутри директории и затем воспользоваться rmdir для удаления самой директории:
$ mkdir mydir
$ touch mydir/file1
$ rm mydir/file1
$ rmdir mydir
Этот метод широко известен под названием «способ удаления директорий для лохов». Все реальные пацаны и админы-гуру съевшие пользователя
собаку на этом деле, используют гораздо более удобную команду rm -rf, описанную далее.
Самый лучший способ удалить директорию состоит в использовании опций «рекурсивного принуждения» (recursive force) команды rm, чтобы приказать ей удалять указанную директорию, также как и объекты содержащиеся внутри:
$ rm -rf mydir
Обычно, rm -rf является наиболее предпочтительным методом для удаления древа директорий. Будьте очень осторожны, когда пользуетесь rm -rf, так как ее мощь может быть использована по обе стороны: добра и зла. =)
Об авторах
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
. В свободное от программирования время Эйрон предпочитает размыщлять над проблемами программирования катаясь на своем велосипеде, жонглируя битами, или болея за бостонскую профессиональную бейсбольную команду «Красные Носки».
