Каталоговая запись

Cтраница 2

Возникает очевидный вопрос: Как файловая система Windows 98 отличает каталоговые записи, содержащие имя файла в формате MS-DOS, от фрагментов длинных имен. Для фрагмента длинного имени это поле содержит значение OxOF, что соответствует невозможной комбинации атрибутов для описателя файла в MS-DOS. Старые программы, написанные для работы в MS-DOS, читая каталог, просто игнорируют такие описатели как неверные. Порядок фрагментов имени учитывается в первом байте каталоговой записи. Поскольку для порядкового номера используется всего 6 бит, теоретически максимальная длина имени файла может составить 63 х 13 819 символов. На практике она ограничена 260 символами по историческим причинам. [16]

Формат каталоговой записи стандарта ISO 9660 показан на рис. 6.26. Поскольку каталоговые записи могут быть переменной длины, первое поле записи представляет собой байт, содержащий длину записи. Во избежание любых двусмысленностей стандартом определено, что старший бит этого байта располагается слева. [17]

Файл, которому требуется три записи MFT для хранения данных обо всех своих сегментах.| Запись MFT для небольшого каталога. [18]

Запись MFT для небольшого каталога показана на рис. 11.20. Запись MFT содержит несколько каталоговых записей, каждая из которых описывает файл или каталог. Фиксированная часть содержит индекс записи MFT файла, длину имени файла, а также другие разнообразные поля и флаги. Поиск файла в каталоге по имени состоит в последовательном переборе всех имен файлов. [19]

Имя формата MS-DOS хранится в каталоге прямо в описателе, показанном на рис. 6.30. Если у файла есть также длинное имя, оно хранится в одной или нескольких каталоговых записях, предшествующих описателю файла с именем в формате MS-DOS. Каждая такая запись содержит до 13 символов формата Unicode. Элементы имени хранятся в обратном порядке, начинаясь сразу перед описателем файла в формате MS-DOS и последующими фрагментами перед ним. [20]

Формат каталоговой записи с фрагментом длинного имени файла в Windows 98. [21]

Корневой каталог и все остальные каталоги могут содержать переменное количество записей, в последней из которых установлен специальный бит, помечающий эту запись как последнюю. Сами каталоговые записи также могут иметь переменную длину. Каждая запись содержит от 10 до 12 полей, некоторые из них содержат текст формата ASCII, а другие являются числовыми двоичными полями. Следовательно, 16-разрядное число занимает 4 байт, а 32-разрядное число 8 байт. Такое избыточное кодирование было использовано при разработке стандарта, чтобы никого не обидеть. Если бы стандарт учитывал только один из способов хранения двоичного числа, тогда сотрудники компаний, в которых применяется другой способ, посчитали бы, что их отнесли к гражданам второго сорта и не приняли бы стандарт. Таким образом, эмоциональное содержание CD-ROM может быть точно измерено в килобайтах потерянного пространства. [23]

Записи каталогов могут иметь расширенные атрибуты. Если для каталоговой записи используется это свойство, тогда второй байт содержит длину записи расширенных атрибутов. [24]

Файловая система, содержащая совместно используемый файл. [25]

Совместное использование файлов удобно, но в то же время создает некоторые новые проблемы. Если дисковые адреса содержатся в самих каталоговых записях, тогда при добавлении новых данных к совместно используемому файлу новые блоки будут числиться только в каталоге того пользователя, который производил эти изменения с файлом. Другим пользователям эти изменения будут не видны. [26]

Последние два поля не всегда присутствуют. Поле Padding ( заполнение) используется для выравнивания размера каталоговой записи до четного количества байтов, чтобы выровнять записи в каталоге по 2-байтовым границам. Если требуется выравнивание, используется нулевой байт. Наконец, функция и размер последнего поля System use ( Sys на рисунке) никак не определяются стандартом. В стандарте указывается лишь, что это поле должно состоять из четного числа байтов. В различных операционных системах это поле используется различным образом. [27]

Когда операционная система перезагружается после сбоя, как правило, выполняется программа восстановления. Предположим, эта программа обнаруживает, что значение счетчика связей в i-узле равно 2, тогда как только одна каталоговая запись ссылается на данный i-узел. Может ли программа восстановления исправить такую ошибку, и если да, то как. [28]

Каталог BSD с тремя файлами ( а. тот же каталог после удаления файла. [29]

На рис. 10.19, б показан тот же самый каталог после того, как файл voluminous был удален. Все, что при этом делается в каталоге, - увеличивается размер записи предыдущего файла colossal, а байты каталоговой записи удаленного файла voluminous превращаются в заполнители первой записи. Впоследствии эти байты могут использоваться для записи при создании нового файла. [30]

Страницы: 1 2 3