архив
Мир на трёх кашалотах мается
2. Файлы
Глава из книги Сага о FreeBSD
Алексей Федорчук
2008-11-19
Символические ссылки
Как уже было сказано, жесткая ссылка на файл может существовать только в той же файловой системе, в которой размещен его inode. Однако подчас возникает необходимость поместить имена одних и тех же файлов в каталогах, лежащих в разных файловых системах (и из главы о файловой иерархии станет ясно, зачем это может понадобиться). Конечно, такие файлы можно просто скопировать. Однако это, помимо напрасной траты дискового пространства, влечет за собой и другие неудобства. В частности, нельзя гарантировать идентичности содержимого таких файлов-копий — а в ряде случаев именно идентичность от них и требуется.
Кроме требования нахождения в одной файловой системе, на жесткие ссылки накладывается еще одно ограничение: они могут быть созданы только на обычные или специальные файлы (например, файлы устройств), но не на каталоги. И потому не подходят для воспроизведения отдельных ветвей файловой иерархии, в чем подчас также возникает необходимость.
Для разрешения этих проблем был придуман особый тип файлов — символические ссылки (symlinks), часто называемые просто ссылками (links). Будем так поступать и мы. А для отличия от них жестких ссылок последние будут именоваться полностью. Вообще-то, в русском языке для однозначности за жесткими ссылками хорошо бы закрепить термин "связь", но он почему-то не прижился.
В отличие от жесткой ссылки, представляющей собой просто еще одно имя для одного и того же набора метаданных и данных, символическая ссылка — это именно самостоятельный файл, со своим идентификатором и прочими атрибутами, записанными в области метаданных, и со своими данными. Другое дело, что последние предоставляют очень ограниченную информацию. А именно — просто указание пути к собственно файлу или каталогу, на который эта ссылка указывает. Причем файл этот может лежать не только на иной файловой системе (дисковом разделе), но даже находиться на иной машине в локальной или даже глобальной сети. Не возбраняются и символические ссылки на каталоги — в этом случае содержимое каталога-ссылки будет точно воспроизводить внутреннюю иерархию исходного каталога.
Собственно говоря, на локализацию файла, исходного для символической ссылки, не накладывается практически никаких ограничений. Потому что при обращении к файлу-симлинку (например, при вызове его для редактирования в текстовом редакторе) происходит отслеживание пути до исходного файла, который и загружается данной программой.
Очевидно, что если исходный файл по каким-либо причинам недоступен (например, лежит на удаленной машине, связь с которой в данный момент отсутствует), любое обращение к нему окажется невозможным — последует просто сообщение об ошибке. Аналогично будет и при обращении к симлинку, исходный файл которого был удален — такие ссылки называются мертвыми.
Роль символических ссылок во FreeBSD очень велика. Во-первых, с их помощью обеспечивается совместимость с файловыми иерархиями любых Unix-подобных систем — написанные для них программы могут искать требующиеся им для работы компоненты (в частности, системные библиотеки) в совершенно определенных каталогах. А те в разных Unix-клонах вполне могут оказаться не только в разных местах, но и на разных файловых системах. И тут символические ссылки оказываются незаменимыми — достаточно продублировать ими требуемые ветви файловой системы в соответствующих местах, чтобы данное приложение спокойно находило все, что ему нужно.
Есть и другое применение символических ссылок. Некоторые программы требуют для своей работы не просто определенные компоненты, чаще всего — библиотеки, но и фиксированные их версии. В то же время установленная в данной системе версия может быть иной — более старой или более новой. В первом случае все ясно — программа, запрашивающая более новую версию, в системе с версией более старой, работать, скорее всего, просто не будет.
А что делать, если версия библиотеки — более новая? Ведь большинство разработчиков программ для для FreeBSD и любых иных Unix-подобных систем обычно свято придерживаются принципа обратной совместимости. То есть функциональность новой версии библиотеки будет, как правило, заведомо достаточной для работы программы, требующей версии более старой. Однако просит-то наша программа именно конкретную версию библиотеки, и, не обнаружив ее, выдает сообщение об ошибке.
Конечно, теоретически правильно написанная программа должна требовать версии не ниже некоторой определенной, однако на практике такая ситуация встречается сплошь и рядом. И разрешается она часто достаточно легко — посредством механизма тех же символических ссылок. То есть обычно достаточно создать симлинк библиотеки имя_рек.5 на имя_рек.6, чтобы обмануть наше приложение и заставить его работать правильно.
Сказанным не исчерпывается сфера применения символических ссылок. В частности, они часто требуются для корректного доступа ряда программ к определенным файлам устройств. Впрочем, это уже тема следующего раздела, имя которому так и будет —
Файлы устройств
Файлы устройств соответствуют различным присутствующим в системе устройствам. Устройства эти могут быть реальными (жесткие диски, принтеры и т.д.), а могут — так называемыми псевдоустройствами, с которыми не ассоциировано никакого "железа" (например, устройство /dev/null, не содержащее ничего, или /dev/zero, содержимое которого — сплошные нули).
Пользователь Linux, вероятно, успел привыкнуть к тому, что файлы устройств разделяются на два подтипа — устройства символьные, с побайтным доступом (последовательные и параллельные порты, терминалы и так далее) и блочные, обмен данными с которыми осуществляется последовательностями байтов фиксированной длины, блоками (жесткие диски и другие накопители).
Некогда так было и во FreeBSD. Однако, начиная с 5-й ветки, одновременно с появлением файловой системы устройств (о которой см. ниже), интерфейс блочного доступа к дискам был удалён, и ныне все устройства предстают перед системой как символьные.
Ранее файлы устройств во FreeBSD были фиксированными, создаваясь при инсталляции системы по специальному сценарию на все случаи жизни, в том числе и для устройств, которых реально на данной машине не было и не предвиделось. Однако в 5-й ветке нашей ОС появилась поддержка файловой системы устройств (devfs). Она обеспечивает динамическое воссоздание файлов устройств при старте системы — каждый раз заново на основе тестирования наличного оборудования. И тут уже файлы создаются только для тех устройств, которые присутствуют на самом деле (и, что немаловажно, поддерживаются текущей конфигурацией ядра системы — в противном случае устройства все равно, что нет). Подробнее о файловой системе устройств будет говориться в соответствующей главе.