Каталоги и служебные данные файлов

 

Данная глава продолжает подъем по кривой обучения до следующего плато: понимания каталогов и информации о файлах.

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

 

Просмотр содержимого каталога

 

Все Unix‑системы, включая Linux, используют для хранения файловой информации на диске один и тот же концептуальный дизайн. Хотя в реализации дизайна есть значительные вариации, интерфейс на уровне С остается постоянным, давая возможность писать переносимые программы, которые компилируются и запускаются на многих различных системах.

 

Определения

 

Рис. Copyright 1997‑2004 © J.D. «Illiad» Frazer. Использовано по разрешению, http://www.userfriendly.org

Мы начнем обсуждение с определения нескольких терминов.

Раздел (partition)

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

Файловая система (filesystem)

Раздел (физический или логический), содержащий данные файла и служебные данные (metadata), информацию о файлах (в противоположность содержимому файла, которое является информацией в файле). Такие служебные данные включают владельца файла, права доступа, размер и т.д., а также информацию, использующуюся операционной системой при поиске содержимого файла. Файловые системы размещаются «в» разделах (соотношение одни к одному) посредством записи в них стандартной информации. Это осуществляется программой уровня пользователя, такой, как в GNU/Linux или в Unix. (Команда Unix создает разделы, но ее трудно использовать, непосредственно, вызывает ее с нужными параметрами. Если ваша система является системой Unix, подробности см. в справочных страницах для newfs (8) и mkfs (8).)

Большей частью GNU/Linux и Unix скрывают наличие файловых систем и разделов. (Дополнительные подробности приведены в разделе 8.1 «Монтирование и демонтирование файловых систем».) Доступ ко всему осуществляется через пути, безотносительно к тому, на каком диске расположен файл. (Сравните это с почти любой коммерческой операционной системой, такой, как OpenVMS, или с поведением по умолчанию любой системы Microsoft.)

Индекс (inode)

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

Устройство (device)

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

Каталог (directory)

Специальный файл, содержащий список пар (индекс, имя). Каталоги могут быть открыты для чтения, но не для записи; все изменения в содержимом каталога делает операционная система.

Концептуально каждый дисковый блок содержит либо некоторое число индексов, либо данные файла. Индекс, в свою очередь, содержит указатели на блоки, содержащие данные файла. См. рис. 5.1.

Рис. 5.1. Концептуальное представление индексов и блоков данных

На рисунке показаны все блоки индексов перед разделом и блоки данных после них. Ранние файловые системы Unix были организованы именно таким способом. Однако, хотя все современные системы до сих пор содержат индексы и блоки данных, их организация для повышения эффективности и устойчивости была изменена. Детали меняются от системы к системе, и даже в рамках систем GNU/Linux имеется множество разновидностей файловых систем, но концепция остается той же самой.

 

Содержимое каталога

 

Каталоги устанавливают связь между именем файла и индексом. Элементы каталога содержат номер индекса и имя файла. Они содержат также дополнительную учетную информацию, которая нам здесь не интересна. См. рис. 5.2.

Рис. 5.2. Концептуальное содержание каталога

На ранних Unix‑системах были двухбайтные номера индексов, а имена файлов – до 14 байтов. Вот полное содержание файла V7:

 

 

 определен в V7 как ''. Поскольку на PDP‑11 является 16‑разрядным, таким же является и. Такая организация упрощала непосредственное чтение каталогов; поскольку размер элемента был фиксирован, код был простым. (Единственно, за чем нужно было следить, это то, что полное 14‑символьное не завершалось символом NUL.)

Управление содержанием каталога для системы также было простым. Когда файл удалялся из каталога, система заменяла номер индекса двоичным нулем, указывая, что элемент каталога не используется. Новые файлы могли потом использовать пустой элемент повторно. Это помогало поддерживать размер самих файлов каталогов в приемлемых рамках. (По соглашению, номер индекса 1 не используется; первым используемым индексом всегда является 2. Дополнительные сведения приведены в разделе 8.1 «Монтирование и демонтирование файловых систем».)

Современные системы предоставляют длинные имена файлов. Каждый элемент каталога имеет различную длину, с обычным ограничением для компонента имени файла каталога в 255 байтов. Далее мы увидим, как читать на современных системах содержимое каталога. Также в современных системах номера индексов 32 (или даже 64!) разрядные.

 

Прямые ссылки

 

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

echo hello, world > message

ls ‑il message

 

Поскольку элементы каталога связывают имена файлов с индексами, у одного файла может быть несколько имен. Каждый элемент каталога, ссылающийся на один и тот же индекс, называется ссылкой (link) или прямой ссылкой (hard link) на файл. Ссылки создаются с помощью команды. Она используется следующим образом: ' старый_файл новый_файл '.

Ln message msg

Cat msg

 

ls ‑il msg message

 

 

Вывод показывает, что номера индексов двух файлов одинаковые, а третье поле расширенного вывода теперь равно 2. Это поле показывает счетчик ссылок, указывающий, сколько имеется ссылок (элементов каталога, ссылающихся на данный индекс) на данный файл.

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

echo "Hi, how ya doin'?" > msg

Cat message

 

ls ‑il message msg

 

 

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

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

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

Rm message

echo "What's happenin?" > message

ls ‑il msg message

 

 

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

 

 

При успешном создании ссылки возвращается 0, в противном случае (‑1), при этом errno отражает ошибку. Важным‑случаем ошибки является тот, когда уже существует. Система не удалит его для вас, поскольку попытка сделать это может вызвать несовместимости в файловой системе.

 

Программа GNU link

 

Программа сложная и большая. Однако, GNU Coreutils содержит несложную программу, которая просто вызывает со своими двумя аргументами. Следующий пример показывает код из файла, не относящиеся к делу части удалены. Номера строк относятся к действительному файлу.

 

Строки 67–75 являются типичным шаблоном Coreutils, устанавливающими интернациональные настройки, выход по завершении и анализ аргументов. Строки 79–95 гарантируют, что вызывается лишь с двумя аргументами. Сам системный вызов осуществляется в строке 97 (Функция обеспечивает отображение аргументов в стиле, подходящем для текущей локали; подробности сейчас несущественны.)

 

5.1.3.2. Точка и точка‑точка

 

Завершая обсуждение ссылок, давайте взглянем на то, как обрабатываются специальные имена '' и ''. На самом деле они просто являются прямыми ссылками. В первом случае '' является прямой ссылкой на каталог, содержащий ее, а '' – прямой ссылкой на родительский каталог. Операционная система создает для вас эти ссылки; как упоминалось ранее, код уровня пользователя не может создать прямую ссылку на каталог. Этот пример иллюстрирует ссылки:

Pwd

 

ls ‑ldi /tmp

 

Mkdir x

ls ‑ldi x

 

ls ‑ldi x/. x/..

 

 

Родительский каталог корневого каталога () является особым случаем; мы отложим его обсуждение до главы 8 «Файловые системы и обход каталогов».

 

 

Переименование файлов

 

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

1. Если новое имя файла обозначает существующий файл, сначала удалить этот файл.

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

3. Удалить старое имя (ссылку) для файла. (Удаление имен обсуждается в следующем разделе.)

Ранние версии команды mv работали таким способом. Однако, при таком способе переименование файла не является атомарным; т.е. оно не осуществляется посредством одной непрерываемой операции. И на сильно загруженной системе злонамеренный пользователь мог бы воспользоваться условиями состояния гонки[51], разрушая операцию переименования и подменяя оригинальный файл другим.

По этой причине 4.2 BSD ввело системный вызов:

 

 

На системах Linux операция переименования является атомарной; справочная страница утверждает:

 

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

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

 

Как и в случае с другими системными вызовами, возвращенный 0 означает успех, а (‑1) означает ошибку.

 

Удаление файла

 

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

Системный вызов называется:

 

В нашем обсуждении ссылок на файлы имя имеет смысл; этот вызов удаляет данную ссылку (элемент каталога) для файла. Она возвращает 0 в случае успеха и ‑1 при ошибке. Возможность удаления файла требует права записи лишь для каталога, а не для самого файла. Этот факт может сбивать с толку, особенно начинающих пользователей Linux/Unix. Однако, поскольку операция в каталоге одна, это имеет смысл; меняется именно содержимое каталога, а не содержимое файла[52].

 

Удаление открытых файлов

 

С самых первых дней Unix было возможно удалять открытые файлы. Просто вызовите с именем файла после успешного вызова или.

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

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

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

 

 

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

 

Использование ISO С:

 

ISO С предоставляет для удаления файлов функцию; она предназначена в качестве обшей функции, годной для любой системы, поддерживающей ISO С, а не только для Unix и GNU/Linux:

 

Хотя технически это не системный вызов, возвращаемое значение в том же стиле: 0 в случае успеха и ‑1 при ошибке, причем содержит значение ошибки.

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

 

 

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

 

Мы начали главу с обсуждения разделов, файловых систем и индексов. Мы также увидели, что элементы каталога связывают имена с номерами индексов. Поскольку элементы каталога не содержат другой информации, прямые ссылки ограничены файлами внутри одной и той же файловой системы. Это должно быть; нет способа отличить индекс 2341 одной файловой системы от индекса 2341 другой файловой системы. Вот что случится, если мы попытаемся это сделать:

Mount

 

ls ‑li /tmp/message

 

Cat /tmp/message

 

/bin/pwd

 

Ln /tmp/message.

 

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

Чтобы обойти это ограничение, 4.2 BSD ввело символические ссылки (symbolic links, называемые также soft links). Символическая ссылка является особой разновидностью файла (также, как особой разновидностью файла является каталог). Содержимое этого файла представляет собой путь к файлу, на который данный файл «указывает». Все современные Unix‑системы, включая Linux, предусматривают символические ссылки; конечно, они теперь являются частью POSIX.

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

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

/bin/pwd

 

ln ‑s /tmp/message./hello

Cat hello

 

ls ‑l hello

 

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

Rm /tmp/message

Cat./hello

 

echo hi again > hello

ls ‑l /tmp/message

 

Cat /tmp/message

 

Символические ссылки создаются с помощью системного вызова:

 

Аргумент содержит указываемый файл или каталог, a является именем создаваемой символической ссылки. При успехе возвращается 0, а при ошибке (‑1), возможные значения см. в справочной странице для symlink (2). У символических ссылок есть свои недостатки:

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

• Они добавляют лишние накладные расходы. Ядро должно больше работать для разрешения имени пути, содержащего символические ссылки.

• Они могут создать «циклы». Рассмотрите следующее:

rm ‑f a b

ln ‑s a b

ln ‑s b a

Cat а

 

Ядро должно быть способно определить такой случай и выдать сообщение об ошибке.

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