Файлы, файлы, файлы

Человеку, ранее работавшему с DOS или Windows, при общении с Linux прежде всего бросаются в глаза использование символа `/? вместо ??, отсутствие имен дисков (A:, B:, C: и т. д.) и то, что в именах файлов различаются большие и маленькие буквы.

Виктор Хименко

Человеку, ранее работавшему с DOS или Windows, при общении с Linux прежде всего бросаются в глаза использование символа `/? вместо ??, отсутствие имен дисков (A:, B:, C: и т. д.) и то, что в именах файлов различаются большие и маленькие буквы. Однако другие особенности, не столь заметные с первого взгляда, более существенны. Давайте посмотрим, как устроена в Linux работа с файлами.

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

Хотя Linux поддерживает более десятка самых разных файловых систем, все «иностранные» (foreign) системы так или иначе маскируются под стандартно используемую в этой ОС ext2fs. Давайте с нее и начнем.

Узлы и каталоги

Во времена юности Unix, когда автор Linux еще не ходил в школу, работа с файлами в этой ОС была организована весьма просто: все файлы на диске нумеровались и для каждого создавалась специальная запись — узел (inode; к сожалению, устоявшегося русского перевода этого термина пока нет), где содержалась служебная информация о файле. Имя в состав этой информации не включалось, а связывалось с узлом с помощью ссылки (link). Ссылки оформлялись как пары вида «имя файла — номер узла» и хранились в каталогах. Каталог можно было читать, как обычный файл, однако для его модификации уже тогда требовалось использовать специальные команды.

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

Сколько имен у файла?

Описанная схема позволяет связать с одним файлом несколько равноправных имен, что в ряде случаев бывает полезно. Сравните, например, характеристики файлов unzip и zipinfo на рис. 1 и 2 (для получения информации использована программа Midnight Commander).

Рис. 1. Характеристики файла unzip

Как видим, они совпадают: у обоих файлов одно и то же «положение» (кстати, шестнадцатеричное число 1A328h является номером узла), одинаковая длина и т. д., причем на каждый из файлов имеется по две ссылки — это в действительности и есть два имени. Но, будучи физически одним и тем же файлом, unzip и zipinfo являются различными программами: каждая из них выполняет свои действия и имеет собственный набор опций. Никакой мистики здесь нет — просто в программу в качестве нулевого параметра передается ее имя, по которому она и определяет, что делать дальше.

Рис. 2. Характеристики файла zipinfo

Далее, в Unix-системах (включая Linux) нет операции удаления файла в смысле DOS/Windows: есть только удаление ссылки на узел — unlink — и ссылки на пустой каталог — rmdir (в некоторых Unix-системах unlink позволяет удалить ссылку на пустой каталог, но в Linux это не так). Сам же файл удаляется автоматически тогда, когда делается недоступным для системы. Это означает, что не должно остаться, во-первых, ни одной ссылки на него, а во-вторых, ни одной работающей с ним активной программы.

Именно поэтому, кстати, в Linux можно обойтись без перезагрузки практически при любом изменении системы (за исключением замены ядра). Чтобы обновить системную библиотеку, вы стираете ее прежнюю версию (т. е. освобождаете соответствующую ссылку) и записываете под тем же именем новую. Ядро откладывает момент удаления библиотеки до тех пор, пока не закончит работу последняя из программ, ее использующих (что может произойти много месяцев спустя). Это весьма удобно, но если не знать о таком поведении системы, можно попасть в неприятную ситуацию.

Монтирование

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

Чтобы избежать подобных эффектов, любую файловую систему необходимо перед началом работы с ней в явной форме подключить к ОС (смонтировать — mount), а по окончании отключить (размонтировать — unmount). Для этой цели служат команды mount и umount (без n, хотя соответствующее действие называется unmount). Команда mount имеет множество опций (см. врезку «Монтирование: подробности для любознательных»), но обязательных аргументов у ее стандартного варианта два: имя файла блочного устройства и имя каталога. В результате выполнения этой команды файловая система, расположенная на указанном устройстве, подключается к системе таким образом, что ее содержимое заменяет собой содержимое заданного каталога (поэтому для монтирования обычно используют пустой каталог). Команда umount выполняет обратную операцию — отсоединяет файловую систему, после чего накопитель можно извлечь и положить на полку (на самом деле проблемы возникают почти исключительно с дискетами: CD-ROM, магнитно-оптический диск или Zip-диск, который забыли размонтировать, просто не удастся вытащить без помощи скрепки — он блокируется).

Такие разные файлы

Осталось выяснить, что такое файл блочного устройства. Для этого следует рассказать о том, какие вообще «звери» встречаются в файловой системе. Очевидно, там есть обычные файлы и каталоги, но это далеко не все. Файлами с точки зрения Linux являются также:

• символьные устройства;
• блочные устройства;
• именованные каналы (named pipes);
• гнезда (sockets);
• символьные ссылки (symlinks).

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

Символьные и блочные устройства

Файлы символьных и блочных устройств создаются с помощью программы mknod и соответствуют внешним устройствам, а также псевдоустройствам, таким как знаменитое пустое устройство /dev/null (такое, при попытке чтения из которого сразу же сообщается о достижении конца файла и при записи в которое никогда не происходит переполнения — точный аналог NUL в DOS/Windows).

Устройства нумеруются двумя целыми числами — старшим (major number) и младшим (minor number). Первое из них соответствует типу устройства (например, для устройств, подключенных к первому IDE-контроллеру, оно равно 3, для подключенных ко второму — 22 и т. д.), а второе — конкретному устройству (например, для мастер-диска, подключенного к первому IDE-контроллеру, оно равно 0, для первого раздела на этом диске — 1 и т. д.). При этом символьные и блочные устройства нумеруются независимо.

Число 30Ah в поле «положение» информации о файлах /usr/bin/unzip и /usr/bin/zipinfo на рис. 1 и 2 обозначает как раз номер устройства: 3 — это первый IDE-диск, а 0A — его десятый раздел.

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

Многие устройства имеют дополнительные характеристики: скажем, на консоли (виртуальной) IBM PC есть три лампочки — Num Lock, Caps Lock и Scroll Lock, — а последовательный порт может передавать данные с различной скоростью. Как правило, программы в Linux работают просто с файлами, никак или почти никак не учитывая особенности того или иного конкретного устройства. Если же программа должна их учитывать, она осуществляет управление соответствующими параметрами через системный вызов ioctl, позволяющий, например, зажечь Num Lock или изменить громкость звука. В основном использование ioctl сводится к управлению конфигурацией (отсюда и название — I/O ConTroL, т. е. управление вводом-выводом).

Основной недостаток описанной схемы в том, что она плохо масштабируется: различных устройств существует великое множество, и поскольку всякое устройство, потенциально подключаемое к компьютеру, должно получить номер (а многие — несколько номеров), этих самых номеров явно не хватает. Кроме того, хотя в каталоге /dev, где традиционно хранятся файлы устройств, представлен, разумеется, далеко не весь спектр аппаратуры (только для SCSI-устройств потребовалось бы завести не одну тысячу файлов), он все-таки обычно содержит более тысячи файлов, и лишь очень малая их часть соответствует устройствам (или псевдоустройствам), реально присутствующим в системе.

Эта проблема была осознана достаточно давно, и уже предложено несколько вариантов ее решения. Однако самым распространенным остается пока стандартный подход, когда все файлы устройств создаются вручную программой mknod. Мне представляется наиболее удачным вариант с использованием специальной файловой системы devfs, монтируемой в каталог /dev, в которой специальные файлы устройств создаются и уничтожаются автоматически по мере надобности (именно так настроен компьютер, где сейчас пишутся эти строки).

Именованные каналы

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

Гнезда

Вообще гнезда (и взаимодействие программ при помощи гнезд) играют очень важную роль во всех Unix-системах, включая и Linux: они являются ключевым понятием TCP/IP и соответственно на них целиком строится Internet. Однако c точки зрения файловой системы гнезда практически неотличимы от именованных каналов: это просто метки, позволяющие связать несколько программ. После того как связь установлена, общение программ происходит без участия файла гнезда: данные передаются ядром ОС непосредственно от одной программы к другой*.

15.02.2000г