Добавлен: 29.10.2018
Просмотров: 48100
Скачиваний: 190
306
Глава 4. Файловые системы
стве исторического отступления заметим, что несколько десятилетий назад, когда
в компьютерном мире властвовали перфокарты на 80 столбцов, многие операционные
системы универсальных машин в основе своей файловой системы использовали файлы,
состоящие из 80-символьных записей, — в сущности, образы перфокарт. Эти опера-
ционные системы поддерживали также файлы, состоящие из 132-символьных запи-
сей, предназначавшиеся для строковых принтеров (которые в то время представляли
собой большие печатающие устройства, имеющие 132 столбца). Программы на входе
читали блоки по 80 символов, а на выходе записывали блоки по 132 символа, даже
если заключительные 52 символа были пробелами. Ни одна современная универсаль-
ная система больше не использует эту модель в качестве своей первичной файловой
системы, но, возвращаясь к временам 80-столбцовых перфокарт и 132-символьной
принтерной бумаги, следует отметить, что это была весьма распространенная модель
для универсальных компьютеров.
Третья разновидность структуры файла показана на рис. 4.2, в. При такой организации
файл состоит из дерева записей, необязательно одинаковой длины, каждая из которых
в конкретной позиции содержит ключевое поле. Дерево сортируется по ключевому
полю, позволяя выполнять ускоренный поиск по конкретному ключу.
Здесь основной операцией является не получение «следующей» записи, хотя возмож-
но проведение и этой операции, а получение записи с указанным ключом. Для файла
зоопарк
(см. рис. 4.1, в) можно, к примеру, запросить систему выдать запись с ключом
пони, нисколько не заботясь о ее конкретной позиции в файле. Более того, к файлу
могут быть добавлены новые записи, и решение о том, куда их поместить, будет при-
нимать не пользователь, а операционная система. Совершенно ясно, что этот тип файла
отличается от бессистемных битовых потоков, используемых в UNIX и Windows, и он
используется в некоторых больших универсальных компьютерах, применяемых при
обработке коммерческих данных.
4.1.3. Типы файлов
Многие операционные системы поддерживают несколько типов файлов. К примеру,
в системах UNIX (опять же включая OS X) и Windows имеются обычные файлы и ка-
талоги. В системе UNIX имеются также символьные и блочные специальные файлы.
Обычными
считаются файлы, содержащие информацию пользователя. Все файлы на
рис. 4.1 являются обычными. Каталоги — это системные файлы, предназначенные для
поддержки структуры файловой системы. Мы рассмотрим их чуть позже. Символьные
специальные файлы
имеют отношение к вводу-выводу и используются для модели-
рования последовательных устройств ввода-вывода, к которым относятся терминалы,
принтеры и сети. Блочные специальные файлы используются для моделирования
дисков. В данной главе нас в первую очередь будут интересовать обычные файлы.
Как правило, к обычным файлам относятся либо файлы ASCII, либо двоичные файлы.
ASCII-файлы состоят из текстовых строк. В некоторых системах каждая строка завер-
шается символом возврата каретки. В других системах используется символ перевода
строки. Некоторые системы (например, Windows) используют оба символа. Строки не
обязательно должны иметь одинаковую длину.
Большим преимуществом ASCII-файлов является возможность их отображения и рас-
печатки в исходном виде, также они могут быть отредактированы в любом текстовом
редакторе. Более того, если большое количество программ используют ASCII-файлы для
4.1. Файлы
307
ввода и вывода информации, это упрощает подключение выхода одной программы ко
входу другой, как это делается в конвейерах оболочки. (При этом обмен данными между
процессами ничуть не упрощается, но интерпретация информации, несомненно, стано-
вится проще, если для ее выражения используется стандартное соглашение вроде ASCII.)
Все остальные файлы относятся к двоичным — это означает, что они не являются
ASCII-файлами. Их распечатка будет непонятным и бесполезным набором символов.
Обычно у них есть некая внутренняя структура, известная использующей их про-
грамме.
Например, на рис. 4.2, а показан простой исполняемый двоичный файл, взятый из
одной из ранних версий UNIX. Хотя с технической точки зрения этот файл представ-
ляет собой всего лишь последовательность байтов, операционная система исполнит
его только в том случае, если он будет иметь допустимый формат. Файл состоит из
пяти разделов: заголовка, текста, данных, битов перемещения и таблицы символов.
Заголовок начинается с так называемого магического числа, идентифицирующего
файл в качестве исполняемого (чтобы предотвратить случайное исполнение файла,
не соответствующего данному формату). Затем следуют размеры различных частей
файла, адрес, с которого начинается его выполнение, и ряд битов-флагов. За заголовком
следуют текст программы и данные. Они загружаются в оперативную память и пере-
мещаются с использованием битов перемещения. Таблица символов используется для
отладки.
В качестве второго примера двоичного файла служит архив, также взятый из UNIX (см.
рис. 4.2, б). Он состоит из набора откомпилированных, но не скомпонованных библио-
течных процедур (модулей). Каждому модулю предшествует заголовок, сообщающий
о его имени, дате создания, владельце, коде защиты и размере. Как и в исполняемом
файле, заголовки модулей заполнены двоичными числами. При их распечатке на прин-
тере будет получаться тарабарщина.
Каждая операционная система должна распознавать по крайней мере один тип файла —
собственный исполняемый файл, но некоторые операционные системы распознают
и другие типы файлов. Старая система TOPS-20 (для компьютера DECsystem 20)
дошла даже до проверки времени создания каждого предназначенного для выполне-
ния файла. Затем она находила исходный файл и проверяла, не был ли он изменен
со времени создания исполняемого файла. Если он был изменен, она автоматически
перекомпилировала исходный файл. В терминах UNIX это означает, что программа
make была встроена в оболочку. Использование расширений имен файлов было обя-
зательным, чтобы операционная система могла определить, какая двоичная программа
от какого исходного файла произошла.
Столь строгая типизация файлов создает проблемы, как только пользователь делает
что-нибудь неожиданное для разработчиков системы. Представьте, к примеру, систе-
му, в которой выходные файлы программы имеют расширение
.dat
(файлы данных).
Если пользователь пишет программу форматирования, которая считывает файл с рас-
ширением
.c
(программа на языке C), преобразует его (например, конвертируя в вид
со стандартными отступами), а затем записывает преобразованный файл в качестве
выходного, то выходной файл приобретает тип
.dat
. Если пользователь попытается
предложить этот файл компилятору C, чтобы тот его откомпилировал, система откажет
ему в этом, поскольку у имени файла неверное расширение. Попытки скопировать
file.
dat
в
file.c
будут отвергнуты системой как недопустимые (чтобы уберечь пользователя
от ошибок).
308
Глава 4. Файловые системы
Рис. 4.2. Примеры структур двоичных файлов: а — исполняемый файл; б — архив
Хотя подобное «дружелюбие» по отношению к пользователю и может помочь нович-
кам, оно ставит в тупик опытных пользователей, поскольку им приходится приклады-
вать значительные усилия, чтобы обойти представления операционной системы о том,
что приемлемо, а что нет.
4.1.4. Доступ к файлам
В самых первых операционных системах предоставлялся только один тип доступа
к файлам — последовательный. В этих системах процесс мог читать все байты или
записи файла только по порядку, с самого начала, но не мог перепрыгнуть и считать
их вне порядка их следования. Но последовательные файлы можно было перемотать
назад, чтобы считать их по мере надобности. Эти файлы были удобны в те времена,
когда носителем в хранилищах данных служила магнитная лента, а не диск.
Когда для хранения файлов стали использоваться диски, появилась возможность
считывать байты или записи файла вне порядка их размещения или получать доступ
к записям по ключу, а не по позиции. Файлы, в которых байты или записи могли быть
4.1. Файлы
309
считаны в любом порядке, стали называть файлами произвольного доступа. Они вос-
требованы многими приложениями.
Файлы произвольного доступа являются неотъемлемой частью многих приложений,
например систем управления базами данных. Если авиапассажир заказывает себе
место на конкретный рейс, программа бронирования должна иметь возможность до-
ступа к запи си, относящейся к этому рейсу, не обременяя себя необходимостью пред-
варительного считывания записей, относящихся к нескольким тысячам других рейсов.
Для определения места начала считывания могут быть применены два метода. При
первом методе позиция в файле, с которой начинается чтение, задается при каждой
операции чтения read. При втором методе для установки на текущую позицию предо-
ставляется специальная операция поиска нужного места seek. После этой операции
файл может быть считан последовательно с только что установленной позиции. По-
следний метод используется в UNIX и Windows.
4.1.5. Атрибуты файлов
У каждого файла есть свои имя и данные. Вдобавок к этому все операционные си-
стемы связывают с каждым файлом и другую информацию, к примеру дату и время
последней модификации файла и его размер. Мы будем называть эти дополнительные
сведения атрибутами файла. Также их называют метаданными. Список атрибутов
существенно варьируется от системы к системе. В табл. 4.2 показаны некоторые из
возможных атрибутов, но кроме них существуют и другие атрибуты. Ни одна из су-
ществующих систем не имеет всех этих атрибутов, но каждый из них присутствует
в какой-либо системе.
Первые четыре атрибута относятся к защите файла и сообщают о том, кто может иметь
к нему доступ, а кто нет. Возможно применение разнообразных схем, часть из них мы
рассмотрим чуть позже. В некоторых системах для доступа к файлу пользователь
должен ввести пароль, в этом случае пароль может быть одним из атрибутов файла.
Флаги представляют собой биты или небольшие поля, с помощью которых происходит
управление некоторыми конкретными свойствами или разрешение их применения.
Например, скрытые файлы не появляются в листинге файлов. Флаг архивации пред-
ставляет собой бит, с помощью которого отслеживается, была ли недавно сделана
резервная копия файла. Этот флаг сбрасывается программой архивирования и уста-
навливается операционной системой при внесении в файл изменений. Таким образом
программа архивирования может определить, какие файлы следует архивировать. Флаг
«временный» позволяет автоматически удалять помеченный им файл по окончании
работы создавшего его процесса.
Поля длины записи, позиции ключа и длины ключа имеются только у тех файлов, запи-
си которых можно искать по ключу. Они предоставляют информацию, необходимую
для поиска ключей.
Различные показатели времени позволяют отслеживать время создания файла,
последнего доступа к этому файлу, его последнего изменения. Эти сведения могут
оказаться полезными для достижения различных целей. К примеру, если исходный
файл был изменен уже после создания соответствующего объектного файла, то он
нуждается в перекомпиляции. Необходимую для этого информацию предоставляют
поля времени.
310
Глава 4. Файловые системы
Таблица 4.2. Некоторые из возможных атрибутов
Атрибут
Значение
Защита
Кто и каким образом может получить доступ к файлу
Пароль
Пароль для получения доступа к файлу
Создатель
Идентификатор создателя файла
Владелец
Текущий владелец
Флаг «только для чтения»
0 — для чтения и записи; 1 — только для чтения
Флаг «скрытый»
0 — обычный; 1 — не предназначенный для отображения
в перечне файлов
Флаг «системный»
0 — обычный; 1 — системный
Флаг «архивный»
0 — прошедший резервное копирование; 1 — нуждающийся
в резервном копировании
Флаг «ASCII/двоичный»
0 — ASCII; 1 — двоичный
Флаг произвольного доступа
0 — только последовательный доступ; 1 — произвольный до-
ступ
Флаг «временный»
0 — обычный; 1 — удаляемый по окончании работы процесса
Флаги блокировки
0 — незаблокированный; ненулевое значение — заблокиро-
ванный
Длина записи
Количество байтов в записи
Позиция ключа
Смещение ключа внутри каждой записи
Длина ключа
Количество байтов в поле ключа
Время создания
Дата и время создания файла
Время последнего доступа
Дата и время последнего доступа к файлу
Время внесения последних
изменений
Дата и время внесения в файл последних изменений
Текущий размер
Количество байтов в файле
Максимальный размер
Количество байтов, до которого файл может увеличиваться
Текущий размер показывает, насколько большим является файл в настоящее время. Не-
которые старые операционные системы универсальных машин требуют при создании
файла указывать его максимальный размер, чтобы позволить операционной системе
заранее выделить максимальное место для его хранения. Операционные системы
рабочих станций и персональных компьютеров достаточно разумны, чтобы обойтись
без этой особенности.
4.1.6. Операции с файлами
Файлы предназначены для хранения информации с возможностью ее последующего
извлечения. Разные системы предоставляют различные операции, позволяющие со-