Операционные системы 5 (стр. 18 из 43)

Теперь о хэндлах. Прикладная программа использует хэндлы как некоторые условные номера открытых файлов, конкретное значение хэндла при этом не играет никакой роли (за понятным исключением стандартных хэндлов с 0 по 4). На самом же деле значение хэндла представляет собой не что иное, как индекс записи в таблице JFT данной программы. Первая запись таблицы соответствует хэндлу 0.

На рис. 3‑3 показана связь между хэндлами, таблицами JFT, таблицей SFT и открытыми файлами/устройствами.

Рис. 3‑3

В примере, показанном на рисунке, стандартные хэндлы процесса A используются так, как это по умолчанию делает MS-DOS: хэндлы 0, 1 и 2 указывают на запись SFT, соответствующую консольному устройству CON, хэндл 3 – на запись об устройстве COM1, хэндл 4 –на запись о принтере. У процесса B стандартный вывод перенаправлен на принтер, что отражено в значении элемента 1 из JFT этого процесса. Хэндлы 3 и 4 для процесса B не показаны, чтобы не захламлять рисунок. Остальные показанные на рисунке элементы JFT обоих процессов указывают на записи SFT, описывающие открытые файлы на дисках.

Заметим, что с файлом PICTURE.BMP связаны две записи в таблице SFT. Это означает, что данный файл был открыт в каждом процессе отдельно (но, очевидно, с использованием одного из режимов разделения файла).

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

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

· Что происходит с файлами при завершении программы, которая их открыла? Правила хорошего программистского тона требуют, чтобы программа перед окончанием работы закрыла за собой все файлы. Однако программист может и не выполнить это требование, или программа может завершиться аварийно. В любом случае ОС должна при завершении программы закрыть все ее файлы. Как ОС узнает, какие файлы следует закрыть? Ответ очень простой: достаточно просмотреть таблицу JFT завершаемой программы и найти там все записи, отличные от FF₁₆.

· Использование JFT дает возможность отделить логическое понятие стандартного устройства (в частности, стандартный ввод – хэндл 0 и стандартный вывод – хэндл 1) от конкретных устройств. Перенаправление стандартных устройств выполняется путем изменения значений соответствующих элементов JFT.

3.6.5. Новые версии системы FAT

Структуры данных файловой системы являются одной из наиболее консервативных, плохо поддающихся изменениям характеристик ОС. Проблема заключается в том, что при изменениях структур данных трудно сохранить совместимость с более ранними версиями. Было бы катастрофой, если бы все множество накопленных в мире файлов в системе FAT вдруг перестало читаться в новой версии системы. Тем не менее, некоторые интересные изменения все же удалось ввести при выпуске версий Windows 95 и 98.

В Windows 95 было преодолено досадное ограничение длины имени файла – знаменитое правило «8 + 3». Казалось бы, при размере записи каталога в 32 байта трудно надеяться на длинные имена файлов. Тем не менее, было найдено забавное решение этой проблемы.

Разработчики из Microsoft обратили внимание, что те записи каталога, в которых встречается бессмысленная комбинация битовых атрибутов «скрытый + системный + только чтение + метка тома», просто-напросто игнорируются как системными программами MS-DOS, так и распространенными утилитами других разработчиков. Это дало возможность использовать записи с такой комбинацией для хранения длинного имени файла. По-прежнему для каждого файла в каталоге имеется основная запись в обычном, старом формате, содержащая атрибуты файла, номер первого кластера и обязательное «короткое» имя. Однако если пользователь при создании файла указывает имя, не укладывающееся в стандарт «8 + 3» или содержащее строчные буквы, то перед основной записью будет вставлено нужное количество дополнительных записей с разбитым на кусочки «длинным именем» в кодировке UNICODE (по 2 байта на символ, что позволяет использовать любой известный алфавит). Длина имени, согласно документации, может достигать 255 символов (на самом деле, чуть меньше).

Начиная с Windows 98, появилась возможность использовать новую разновидность файловой системы – FAT-32. Ее отличие от FAT-12 и FAT-16 заключается не только в большей разрядности номера кластера (хотя и это очень важно для больших дисков), но и в том, что Microsoft наконец-то решилась использовать 10-байтовый резерв, который неизвестно для каких целей сохранялся незанятым в каждой записи каталога. Благодаря этому появилась возможность добавить к дате/времени последней модификации файла еще два временных штампа: дату/время создания (на самом деле, это дата/время последнего изменения каталожной записи) и дату последнего доступа к файлу.

3.7. Файловые системы и управление данными в UNIX

3.7.1. Архитектура файловой системы UNIX

Здесь рассматривается классическая файловая система UNIX, называемая иногда системой s5fs и поддерживаемая всеми версиями UNIX. Современные усовершенствования файловой системы будут рассмотрены в п. 3.7.4.

3.7.1.1. Жесткие и символические связи

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

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

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

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

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

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

Можно кратко сказать, что жесткая связь указывает на сам файл, а символическая – на имя файла. Оба типа связей проиллюстрированы на рис. 3‑4.

Рис. 3‑4

В примере на рисунке показан файл данных, для которого имеются три жесткие связи, т.е. три имени в каталогах системы, обозначенные как «Имя 1», «Имя 2» и «Имя 3». Кроме того, в системе имеется файл типа «символическая связь», который содержит одно из имен файла данных. Файл символической связи, как и любой другой файл, доступен по имени и в данном случае имеет два имени (две жестких связи): «Имя 4» и «Имя 5». Таким образом, использование любого из пяти имен в качестве, например, имени открываемого файла приведет к открытию одного и того же файла.

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

В Windows используется некоторый аналог понятия символической связи – ярлык файла (shortcut). Отличие в том, что с точки зрения файловой системы Windows ярлык не является каким-то особым типом файла, это обычный текстовый файл с расширением LNK. Ярлык распознается не файловой системой, а такими программами, как Проводник (Explorer).

3.7.1.2. Монтируемые тома

В UNIX нет понятия «буква диска», подобно буквам A:, C: и т.д., используемым в MS-DOS и в Windows. В системе может быть несколько дисковых томов, но, прежде чем получить доступ к файловой системе любого диска, кроме основного, пользователь должен выполнить операцию монтирования диска. Она заключается в том, что данный диск отображается на какой-либо из каталогов основного тома. Как правило, для этого используются пустые подкаталоги каталога /mount или /mnt.