Основной файловой операцией здесь является не получение следующей записи, хотя это также возможно, а получение записи с указанным значением ключа. Для файла, показанного на рис. 5.1, в, можно, например, запросить у системы запись с ключом пони , не беспокоясь о точном положении записи в файле (вольера в зоопарке). При добавлении новой записи операционная система, а не пользователь должна решать, куда ее поместить. Такой тип файлов принципиально отличается от неструктурированных потоков байтов, применяемых в UNIX и Windows. Как бы то ни было, они широко применяются на больших мэйнфреймах, еще используемых для коммерческой обработки данных.

5.1.3. Типы файлов

Многие операционные системы поддерживают различные типы файлов. Например, в системах UNIX и Windows проводится различие между обычными файлами и каталогами. В системе UNIX также различаются символьные и блочные специальные файлы. К обычным (regular) файлам относятся все файлы, содержащие информацию пользователя. Все файлы на рис. 5.1 являются просто файлами. Каталоги - это системные файлы, обеспечивающие структуризацию файловой системы. Мы рассмотрим их подробнее ниже. Символьные специальные файлы имеют отношение к вводу/выводу и используются для моделирования последовательных устройств ввода/вывода, таких как терминалы, принтеры и сети. Блочные специальные файлы находят применение в моделировании дисков. В данной главе мы в первую очередь будем рассматривать стандартные файлы.

Эти файлы в основном являются либо последовательностями ASCII-строк, либо двоичными наборами байтов. В некоторых системах каждая ASCII-строка завершается символом возврата каретки. В других (например, UNIX) используется символ перевода строки. Есть системы (например, MS-DOS), где используются оба символа. Строки не обязаны иметь одну и ту же длину.

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

Если файлы не являются ASCII-файлами, они причисляются к двоичным. При выводе их на принтер получается невразумительный набор символов, напоминающий свалку мусора. Но в действительности у них есть некая внутренняя структура, известная использующей их программе.

Например, на рис. 5.2, а показан простой исполняемый двоичный файл из состава одной из версий системы UNIX. Хотя технически файл представляет собой всего лишь последовательность байтов, операционная система станет исполнять его только в том случае, если этот файл имеет соответствующий формат. Файл состоит из пяти ра.зделов: заголовка, текста, данных, данных переадреса-

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

-16 битов-

Размер релокационного блока

Магическое число

Размер текста

Размер данных

Размер таблицы символов

Точка входа

Флаги

Текст

Данные

Биты релокации

Табпица символов

Заголовки

Объектный модуль

Заголовки

Объектный модуль

Заголовки

Объектный модуль

Имя модуля

Дата

Владелец

Защита

Размер

Рис. 5.2. а - исполняемый файл; б - архив

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

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

Все операционные системы должны распознавать по крайней мере один тип файлов - свои собственные исполняемые файлы, но некоторые операционные системы различают и другие типы файлов. Старая TOPS-20 (для компьютера DECsystem 20) даже анализировала время создания каждого предоставляемого ей на исполнение файла. Затем она находила исходный файл и проверяла, не был ли он изменен, после того как был создан исполняемый файл. Если оказывалось, что исполняемый файл уже устарел, операционная система автоматически перекомпилировала исходный файл. В переводе на язык понятий UNIX - профамма make была встроена в оболочку. Расширения имен файлов были обязательными, чтобы операционная система могла определить, какая двоичная программа от какого исходного файла произошла.

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

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

5.1.4. Доступ к файлам

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

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

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