1233

поля игнорируются. Метка тома может содержаться только в Root;

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

файлы. Надо стремиться по возможности формировать файлы с длиной, кратной размеру кластера. Во-вторых, не использовать слишком ветвистую и глубокую иерархию директориев. На директорий, как и на любой другой файл, резервируется как минимум один кластер (например, 4К). Учитывая размер элемента директория, получим максимальное число файлов в директории:

4К / 32 = 512 .

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

FAT32

С появлением дисковых накопителей большой емкости все более отчетливо стали проявляться негативные стороны FAT, прежде всего связанные с ограничением на предельное число кластеров. 16-ираз-

рядный элемент FAT позволяет разместить максимальное значение 0xFFFF, а значит, логический диск может быть разделен почти на такое же число кластеров. Размер кластера K, выделяемого файлу при его создании, рассчитывается как

K = V / 0xFFFF,

где V - емкость логического диска и округляется до размера страницы. Например, логический диск емкостью 1.2 гигабайта имеет кластер размером 32К. И это минимум того, что выделяется каждому файлу! Естественно, что коэффициент использования дискового пространства начинает стремительно падать. Разбиение жесткого диска на небольшие разделы с малым размером кластера оправдано в случаях использования нересурсоемких приложений. Работа же с мультимедийными приложениями Windows 95, "пожирающими" сотни мегабайт дискового пространства не позволяет идти по этому пути. Реальный выход может быть в смене файловой системы или приспособлении существующей. Так появилась FAT32.

Что же такое FAT32? Это развитие файловой системы FAT. Принципы работы с FAT32 остались примерно такими же как и с классической файловой системой FAT. FAT32 позволяет выделять на диске большие разделы (более 2 Gb). Кроме этого уменьшается размер кластера на разделе:

Таким образом, при использовании FAT32 рациональнее расходуется дисковое пространство.

FAT32 разрабатывалась как полностью совместимая файловая система для DOS/Windows. Все программы, не работающие с диском напрямую, не заметят никакой разницы при работе с FAT32. Исключение составляют низкоуровневые утилиты класса дисковых утилит. Утилиты, включенные в состав OSR2, полностью поддерживают FAT32.

ФУНКЦИИ WINDOWS API ДЛЯ РАБОТЫ С ДИРЕКТОРИЯМИ

Текущий директорий (каталог, папка) определяется вызовом функции

DWORD GetCurrentDirectory(

которая возвращает протяженность заполненной части буфера или нуль в случае ошибки.

Установка текущего директория может быть выполнена функцией

BOOL SetCurrentDirectory( LPCSTR lpPathName );

Через параметр передается путь к новому текущему директорию приложения. Успешное завершение функции (как и всех последующих, возвращающих логическое значение) соответствует значению true.

LPSECURITY_ATTRIBUTES lpSecurityAttributes // Атрибуты защиты

);

создает новый директорий, путь к которому задается первым параметром, а атрибуты системы защиты - вторым. Как обычно, если права доступа к директорию не ограничиваются, то в качестве lpSecurityAttributes передается значение NULL.

Для удаления директория с полным именемlpPathName следует использовать функцию BOOL RemoveDirectory( LPCSTR lpPathName );

Изменение имени директория осуществляется с помощью вызова функции

BOOL MoveFile(

LPCSTR lpExistingFileName, // Старое имя

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

Просмотр содержимого директория выполняется функциями

LPWIN32_FIND_DATA lpFindFileData // Адрес структуры для раз-

// мещения данных о файле

);

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

typedef struct _WIN32_FIND_DATA {

первому (First) или очередному (Next) файлу.

Схема просмотра содержимого директория такова:

HANDLE hFind; WIN32_FIND_DATA FindFileData; char FileName[256];

...

if((hFind = FindFirstFile(FileName, FindFileData)) != INVALID_HANDLE_VALUE)

{

while( true )

{

// Работа с данными из элемента директория

...

if ( !FindNextFile(hFind, FindFileData) )

{

if( GetLastError() != ERROR_NO_MORE_FILES )

{

// Обработка ошибки

...

}

break;

}

}

FindClose(hFind);

);

позволяет узнать путь к директорию с файлами операционной системы

Windows, а функция

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

Файловая система для Windows 95 - VFAT (Virtual File Allocation Table). Чтобы обеспечить совместимость VFAT с ее предшественником файловой системой FAT, - разработчики были вынуждены пойти на некоторые компромиссы, касающиеся структуры имени.

Дополнение ОС, работающей с именами файлов формата 8.3, возможностями использования длинных имен файлов не означает лишь просто увеличение размера элементов каталога для размещения более 11 символов, поскольку необходима совместимость и с предыдущими версиями. Если в новой ОС записи каталога будут представлены в новом формате, то, переписав файл на гибкий диск под управлением новой системы, вы не сможете прочитать его с помощью старой. Имеется и другая проблема. Если новая ОС будет передавать старым прикладным системам, рассчитанным на прием имен с длиной не более 11 символов, 255-символьные имена, программы ее "не поймут".

Для решения проблемы использования длинных имен при соблюде-

нии полной совместимости со старыми версиями прикладных программ, подготовленными для DOS и Windows, разработчики Windows 95 нашли решение. Как правило прикладные программы (за исключением специальных утилит, использующих для обращения к диску операции низкого уровня - например, Norton Disk Doctor) обращаются к ОС за именами файлов и каталогов не путем прямого считывания с диска соответствующих записей, а через специальные, встроенные в ОС функции. В результате тестирования специалистами Microsoft обнаружено, что, если у некоторого элемента каталога установлена "нереальная" комбинация битов атрибутов: "только для чтения", "скрытый", "системный", "метка тома" - другими словами, если байту атрибутов некоторого элемента каталога присвоить значение 0Fh, - тогда любые функции, имеющиеся во всех существующих версиях DOS и Windows (предшествующих Windows 95), не "заметят" такого элемента каталога, словно его нет.

Витоге для Windows 95 проблема была решена следующим образом: для каждого файла и подкаталога имеются два имени: короткое, "понятное" всем прикладным программам, и длинное - для приложений Windows 95 и тех программ, в которых предусмотрена возможность работы с длинными именами. Для хранения коротких имен в формате

8.3используются обычные 32-байтовые записи. Короткие имена Windows создает из длинных имен, отсекая шесть старших символов и добавляя в конец этого базового имени "1". Если же существует еще одно имя, состоящее из тех же шести символов, то этот номер увеличивается на единицу. Расширение файла сохраняется прежним. Если в имени встречается символ, не допустимый в предыдущих версиях Windows и DOS, он заменяется на знак "подчеркивание" (_).

Длинные имена (LFN) хранятся в специально отформатированных 32-байтовых записях, байт атрибутов у которых равен 0Fh. Для конкретного файла или подкаталога непосредственно перед его единственной записью каталога с его именем в формате 8.3 находится группа из одной или нескольких записей, представляющих длинное имя. Каждая такая запись содержит часть длинного имени файла не более 13 символов, и ОС составляет полное длинное имя из всех записей.

Какие из этого следуют выводы? Если файл с длинным именем записать на гибкий диск, а затем прочитать его на компьютере, работающем под управлением DOS или Windows 3.x, то ОС распознает лишь короткое имя файла и проигнорирует все записи каталога для длинного имени. А поскольку в данном случае ОС "понятно" лишь короткое имя, прикладная программа, запросившая у нее имя файла или подкаталога, не получит неожиданно длинное имя.

ВWindows 95 прикладными программами для 16-разрядных систем DOS и Windows, как и прежде, "видны" лишь короткие имена файлов, поскольку в ответ на их запросы ОС передает имена файлов и подкаталогов в формате 8.3. Чтобы добраться до длинных имен, программа должна обратиться к системным специальным функциям. Во всех прикладных программах для 32-разрядной версии Windows эти функции вызываются по умолчанию, поэтому они автоматически получают доступ к длинным именам.

На рисунке показана структура записи каталога для длинного имени файла. Эти имена хранятся в формате Unicode, т. е. для каждого символа выделяется 2 байт (в отличие от ASCII, где лишь 1 байт). Символы, из которых состоит имя файла, распределяются по трем отдельным полям: первое - длиной 10 байт (5 символов), второе - 12 байт (6 символов) и третье - 4 байт (2 символа).

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

Положение поля атрибутов в записях каталога как для длинных имен, так и формата 8.3 одинаково. Объясняется это тем, что, до тех пор пока файловая система не ознакомится с содержимым байта атрибутов, она не "знает", с каким типом записи она имеет дело в данный момент. Поле с номером начального кластера также находится на прежнем месте, однако в записях каталога для длинных имен его значение всегда равно 0. Поле с указанием типа также содержит 0. Байт с 8-бит контрольной суммой для длинного имени рассчитывается как остаток от деления на 256 суммы значений определенных полей соответствующей записи в каталоге формата 8.3. В Windows 95 контрольная сумма используется для выявления "осиротевших" или испорченных записей в каталоге для длинных имен.

Формирование записи для длинного имени происходит даже в том случае, если оно достаточно коротко и годится для формата 8.3, поскольку для него предусматривается регистр, а для короткого - нет. Ниже показано шестнадцатеричное представление элементов каталога для файла с именем Budget.xls. Короткое имя (BUDGET.XLS) заносится в запись формата 8.3.

Непосредственно перед ней располагается запись для длинного имени, содержащая имя Butget.xls. Порядковый помер данного элемента каталога длинного имени равен 1, шестой бит - также 1, что означает, что текущий элемент не только первый, но и последний. Поскольку записи в каталоге для длинного имени всегда размещаются

непосредственно перед соответствующим элементом каталога формата 8.3, Windows 95, обнаружив для требуемого файла или подкаталога элемент каталога в формате 8.3, легко находит его длинное имя.

Следующий рисунок иллюстрирует, как бы выглядели элементы каталога для короткого и длинного имени файла, если вместо Budget.xls его назвать Budget for Fiscal Year 1999.xls. Поскольку в этом случае длинное имя состоит из 31 символа, потребуется три записи для длинного имени. Обратите внимание на обратный порядок положения элементов: запись с первыми 13 символами длинного имени помещается непосредственно перед коротким именем, следующие 13 символов - перед этой записью; и наконец, в самом начале идет запись, содержащая последние пять символов.

На первый взгляд предложенный VFAT механизм длинных имен файлов позволяет сохранить преемственность с прикладными программами прошлого поколения и выглядит идеальным. Однако этот метод далек от совершенства.

Одна из проблем, присущих использованию длинных имен, заключается в том, что для них требуется больше дискового пространства,чем для коротких имен. Это не имеет существенного значения при хранении длинных имен в подчиненных каталогах, поскольку по мере добавления в каталоги новых записей последние могут расширяться. Однако максимальное число записей в корневом каталоге ограничено, а длинные имена файлов занимают в нем страшно много места. Для большинства жестких дисков в корневом каталоге может содержаться не более 512 записей. Например, для хранения имени из 128 символов потребуется 11 записей (десять для длинного имени и один - для короткого). Поэтому в корневом каталоге удастся разместить лишь 46 файлов и подкаталогов, если название каждого из них состоит из 128 символов. Более серьезная проблема возникает в том случае, когда элементы каталога длинных имен становятся "сиротами". Допустим, вы переписали некоторый файл на гибкий диск, а затем работали с ними на компьютере под управлением DOS или Windows 3.х. Если там удалить или переименовать этот файл, то будет удалена или переименована соответствующая запись для формата 8.3. Однако записи для длинных имен останутся нетронутыми, поскольку ни DOS, ни Windows 3.1 не подозревают об их существовании. Такие записи оказываются "осиротевшими".

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

А как обстоят дела с 16-разрядными программами, работающими под управлением Windows 95? Безопасно ли удаление или переименование файлов с их помощью? К чести Windows 95 она способна "уловить" момент, когда некоторая программа прошлого поколения, не обладающая инструментами работы с длинными именами, производит удаление или переименование файла. В обоих случаях ОС удаляет за-

писи для длинного имени, т. е. они не остаются "осиротевшими". Таким образом, если старая программа переименовывает файл (используя его короткое имя), то исчезает и его длинное имя. Учитывая это, лучше избегать использования длинных имен, если для управления файлами или каталогами вы все еще пользуетесь привычными программами DOS, ориентированными под Windows 3.х.

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

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

Единственный выход из создавшейся ситуации - дефрагментация диска. Утилита Defrag, входящая в состав Windows 95, производит упаковку рабочих записей в каталоге, объединяя свободные записи в единую область. Необходимо регулярно проводить дефрагментацию своих дисков, тем более если вы работаете с длинными именами.

ФАЙЛОВАЯ СИСТЕМА HPFS (OS/2)

Высокоэффективная файловая система HPFS является расширением к операционной системе OS/2 начиная с версии 1.2 и решает все проблемы системы FAT. HPFS не только является способом организации данных на запоминающих устройствах блочного типа, она также является модулем программного обеспечения, который транслирует файловые запросы от прикладных программ в команды управления накопителями. Превосходная производительность достигается использованием расширенных структур данных и некоторых технологий типа интеллектуального кеширования, упреждающего чтения и отложенной записи.

Дисковое пространство распределяется более экономно путем использования разбиения на секторы. HPFS также подразумевает значительно улучшенную отказоустойчивость. Для миграции под новую систему прикладные программы нуждаются только в простых изменени-

ях нужных для возможности использования расширенных атрибутов и длинных имен файлов. Файловая система HPFS была разработана Gordon Letwin, главным разработчиком операционной системы OS/2. HPFS была разработана, чтобы удовлетворить запросы все более и более мощных PC, жестких дисков, сетей в будущем и служить подходящей платформой для написания программ на объектно-ориентированных языках, устойчивой работы прикладных программ и удобных интерфейсов пользователя.

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

Структура тома

HPFS тома - новый тип разделов, которые могут существовать на жестком диске рядом с несколькими предварительно определенными разделами FAT.

HPFS том имеет небольшое количество фиксированных структур. Сектора 0-15 тома содержа имя тома, 32-хбитный идентификатор тома и дисковую программу начальной загрузки. Программа начальной загрузки относительно сложна и может использовать HPFS в усеченном режиме для нахождения и чтения файлов операционной системы

везде, где бы они не находились.

Сектора 16 и 17 известны как SuperBlock и SpareBlock соответственно. SuperBlock могут изменять только утилиты работы с диском. Он содержит указатели на свободное пространство, список плохих блоков, каталоги, и корневой директорий. Он также содержит дату последней проверки и восстановления тома с помощью CHKDSK. SpareBlock содержит различные флажки и указатели, которые будут обсуждаться позже; SpareBlock может изменятся во время работы системы, но это бывает редко.

Остаток диска разделен на участки - полосы - по 8 МБ. Каждая полоса имеет собственный описатель свободного пространства - растр, в котором бит представляет отдельный сектор. Бит равен 0 если сектор находится в использовании и 1 если сектор доступен. Растры размещаются в начале или конце полосы, поэтому растр является смежным с одним из возможных растров соседних полос. Это позволяет выделить для размещения файла максимальное непрерывное свободное пространство 16 МБ. Одна полоса, размещенная ближе к центру диска, называется полосой блока каталогов и специальным образом обрабатывается. Размер полосы - характеристика отдельной реализации и может быть отличной от приведенной в других версиях файловой системы.

Файлы и Fnodes

Каждый файл или каталог на HPFS томе базируется на фундамен-

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

Пространство, зарезервированное для информации распределения в Fnode может содержать указатели на восемь групп секторов до 16 МБ каждая. (Этот размер является только суммой размера полосы и свободного пространства растра размещения и не является ограничением файловой системы). Маленькие файлы или сильно непрерывные файлы, следовательно, могут описываться полностью внутри Fnode.

HPFS использует новый метод представления расположения файлов, являющихся слишком большими или слишком фрагментированными для Fnode и состоящими более чем из восьми групп секторов. Структура распределения Fnode становится корнем для B+дерева секторов распределения, которые содержат фактические указатели к группам секторов файла. Корень Fnode имеет участок памяти для 12 элементов. Каждый сектор распределения может содержать, кроме различной информации управления, не более 40 указателей на группу секторов.

Следовательно, распределение с двумя уровнями B+дерева может описывать файл, имеющий 480 (12 * 40) групп секторов с теоретическим максимальным размером 7.68Gb (12 * 40 * 16 МБ) в отдельной реализации.

Маловероятно, что B+дерева с двумя уровнями будет недостаточно для описания сильно фрагментированного файла, по необходимости файловая система будет представлять дополнительные уровни в дереве. Секторы распределения в промежуточных уровнях могут содержать не более 60 внутренних (нетерминальных) узлов. Например, 3-х уровневое распределение B+дерева может описывать файл с

28,800 (12 * 60 * 40) групп секторов.

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

Каталоги

Каталоги, подобно файлам, базируются на Fnodes. Указатели на Fnode корневой директории находится в SuperBlock. Fnodes для не-

корневых каталогов ищутся через элементы подкаталогов в каталогах их хозяев.

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

Каждый 2 КБ блок каталога содержит от одного до множества элементов каталога. Элемент каталога содержит несколько полей, включая поля времени и даты, Fnode указатель, число для использования дисковыми утилитами, длину файла или имя каталога, само имя, и указатель B-дерева. Каждый элемент начинается словом, которое содержит длину элемента, что позволяет при необходимости очень быстро обходить блок каталога.

Количество элементов в блоке каталога зависит от длины имен. Если средняя длина имени файла - 13 символов, то блок каталога будет содержать приблизительно 40 входов. Элементы в блоке каталога сортируются по полю их имени (для английского алфавита). Последний элемент в блоке каталога - фиктивная запись которая отмечает конец блока.

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

Можно предположить следующую ситуацию для подтверждения эффективности вышеописанных методов.

Примем 40 элементов на блок, тогда дерево с двумя уровнями блоков каталога может содержать 1640 элементов каталога а дерево с тремя уровнями может содержать 65,640 элементов!!! Другими словами, специфический файл может быть найден (или показано его отсутствие) в типичном каталоге с 65,640 файлами с максимально возможными тремя совпадениями - фактическое число операций с диском зависит от содержания кэша и расположения имени файла в блоке каталога B-дерева. Это - полная противоположность FAT, где в самом плохом случае более 4000 секторов нужно прочесть, чтобы установить наличие файла в каталоге, содержащим то же самое число файлов.

Структура каталога B-дерева имеет интересные особенности при некоторых дисковых операциях. Создание файла, переименование, или стирание может приводить к каскаду сложных операций, т.к. блоки каталога добавляются или освобождаются или имена перемещаются из одного блока в другой, а файловая система должна хранить сбалансированное дерево. Теоретически операция переименования может терпеть неудачу из-за отсутствия дискового пространства даже если файл не увеличивается. Чтобы избежать такие неприятности, HPFS поддерживает небольшой пул свободных блоков, которые могут выводиться в аварийный каталог; указатель к этому пулу свободных блоков сохраняется в SpareBlock.

Расширенные атрибуты

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

HPFS поддерживает те же самые атрибуты как и в FAT по историческим причинам, но она также поддерживает новую форму атрибутов, называемую расширенными атрибутами (EA). Каждый EA в принципе подобен системной переменной, принимающей форму имя=значение, за исключением того, что часть значения может быть или ASCIIZ строкой или двоичными данными.

Метод хранения EA может изменяться. Если EA связанные с данным файлом или каталогом достаточно маленькие, то они будут корректно сохранены в Fnode. Если размер EA слишком большой, то они хранятся снаружи Fnode в группах секторов, и B+дерево распределения секторов может создаваться чтобы описать группы. Если одиночный EA становится слишком большим, он может быть помещен снаружи Fnode в собственное B+дерево.

API функции ядра DosQFileInfo и DosSetFileInfo позволяют прикладным программам управлять расширенными атрибутами файлов. Функции DosQPathInfo и DosSetPathInfo используются, чтобы читать или записать EA связанные с произвольными путями. Прикладная программа может или запрашивать значение специфического EA или может получать все EA для файла или каталога сразу.

Мы должны обратить внимание на то, что кроме EA, LAN Manager версия HPFS поддерживает другой класс связанной с файлом информации, называемой контрольный список доступа (ACL). ACL имеют тот же самый вид как EA и управляются подобным способом, но они предназначены для хранения прав доступа, паролей, и другой информации, представляющей интерес для работы с сетями.

Инсталлируемые файловые системы

Поддержка для инсталлируемой файловой системы была одной из наиболее долгожданных особенностей OS/2 1.2. Она сделала возможным обращение к несовместимым по структуре томам - FAT, HPFS, CD ROM на той же самой системе OS/2 в то же самое время.

Устанавливаемый драйвер файловой системы (FSD) является одним из удобных способов доступа к устройству. FSD постоянно находится на диске в файле, который структурно подобен библиотеке динамической компоновки (DLL), обычно с SYS или IFS расширением, и загружается в течение инициализации системы операторами IFS= в файле CONFIG.SYS. Это позволяет загружать драйвер устройства для нестандартного устройства, загружать драйвер файловой системы из тома на том устройстве, и так далее.

Проблемы эффективности

Для повышения производительности HPFS использует расширенные структуры данных, непрерывное распределение, интеллектуальное кеширование, отложенную запись.

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

Следующая основная цель HPFS's - оптимизация распределения файлов в совокупности с управляющими структурами.

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

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

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

Другая стратегия - это присоединение приблизительно 4 КБ непрерывного свободного места к файлу каждый раз когда он должен расширится и отсоединять обратно любой излишек, когда файл закрывается.

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

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

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

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

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

Отказоустойчивость

Обширное использование HPFS ленивых записей делает обязательной для HPFS способность восстанавливаться после ошибок записи в любой ситуации. Ошибки могут быть обнаружены аппаратными средствами ( типа ошибки "sector not found", возвращенной дисковым адаптером ), или они могут быть обнаружены дисковым драйвером, несмотря на аппаратные средства в течение read-after-write проверки данных.

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

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

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

В случае катастрофы, типа потери SuperBlock или корневой директории, HPFS имеет возможность восстановить данные с большой вероятностью правильного восстановления. Каждый тип критического файлового объекта, включающего Fnodes, секторы распределения и блоки каталога, дважды компонуется и со своим родительскими и дочерними записями и содержит уникальную сигнатуру из 32 бит. Fnodes также содержат начальную часть имени их файла или каталога.

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

Файловая система NTFS (Windows NT)

NTFS обеспечивает комбинацию эффективности, надѐжности и

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

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

NTFS является простой, но очень мощной разработкой. Для этой перспективной файловой системы вся информация на томе NTFS является файлом или частью файла. Каждый распределѐнный на томе NTFS сектор принадлежит некоторому файлу. Даже метаданные (metadata) файловой системы (информация, которая описывает непосредственно файловую систему) являются частью файла.

Эта основанная на атрибутах файловая система поддерживает объектно-ориентированные приложения, обрабатывая все файлы как объекты, которые имеют определяемые пользователем и системой атрибуты.

Главная файловая таблица

Каждый файл на томе NTFS представлен записью в специальном файле, называемом главной файловой таблицей (MFT - master file table). NTFS резервирует первые 16 записей таблицы для специальной информации. Первая запись этой таблицы описывает непосредс-

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

Третья запись MFT - файл регистрации (log file), который используется для восстановления файлов.

Семнадцатая и последующие записи главной файловой таблицы используются собственно файлами и каталогами (также рассматриваются как файлы NTFS) на томе. Ниже показана упрощѐнная структура

MFT.

пространства для каждой записи файла. Атрибуты файла записываются в распределѐнное пространство MFT. Небольшие файлы и каталоги

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

Записи каталога помещены внутри главной файловой таблицы так же, как записи файла. Вместо данных каталоги содержат индексную информацию. Небольшие записи каталогов находятся полностью внутри структуры MFT. Большие каталоги организованы в B-tree, имея

записи с указателями на внешние кластеры, содержащие элементы каталога, которые не могли быть записаны внутри структуры MFT.

Атрибуты файла NTFS

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

Если атрибуты файла могут находится внутри записи файла MFT, они называются резидентными (resident) атрибутами. Например, информация типа имени файла и отметки времени всегда включается в запись файла MFT. Если файл слишком большой, чтобы содержать все атрибуты в записи файла MFT, часть атрибутов является нерезидентной (nonresident). Нерезидентные атрибуты занимают один или несколько пробегов (run) дискового пространства в другом месте тома (пробег дискового пространства - непрерывная линейная область на диске).

Вообще, все атрибуты могут быть вызваны как поток байтов независимо от того, являются ли они резидентными или нерезидентными.

В табл. представлен список всех атрибутов файла, в настоящее время определенных для NTFS. Этот список расширяем, т. е. другие атрибуты файла в будущем могут быть определены в случае необходимости.

Длинные и короткие имена файлов

Подобно HPFS, NTFS поддерживает имена файла до 255 символов. Имена файла NTFS используют набор символов Unicode с 16 битами; однако вопрос доступа из MS DOS решен. NTFS автоматически генерирует поддерживаемое MS DOS имя (восемь плюс три символа) для каждого файла. Таким образом, файлы NTFS могут использоваться через сеть операционными системами MS DOS и OS/2. Это особенно важно для файловых серверов организации, которая использует персональные компьютеры с двумя или всеми тремя этими операционными системами.

Создавая короткие имена файла, NTFS также позволяет приложениям MS DOS и Windows З.х работать с файлами, имеющими длинные имена NTFS. Кроме того, при сохранении файла приложениями MS DOS или Windows З.х на томе NTFS сохраняются и имя файла "восемь плюс три" и длинное имя NTFS.

Генерация короткого имени файла

Поскольку NTFS использует набор символов Unicode для имен файлов, существует возможность задействования нескольких "запрещенных" символов, которые MS DOS не может читать в имени файла. Для генерации короткого имени файла в стиле MS DOS, NTFS удаляет все эти символы и любые пробелы из длинного имени файла. Так как имя файла в MS DOS может иметь только одну точку, NTFS также удаляет все дополнительные точки из имени файла. Далее, в случае необходимости NTFS усекает имя файла до шести символов и добавляет тильду (~) и номер. Например, к каждому недублированному имени файла добавляется ~1. Повторяющиеся имена файлов заканчи-

ваются символами ~2, ~3 и т. д. Расширение имени файла усекается до трех или меньшего количества символов. Наконец, при отображении имени файла в командной строке NTFS транслирует все символы

вимени файла и расширении к верхнему регистру (File Manager отображает эти имена файла в нижнем регистре).

Начиная с Windows NT 3.5 используется несколько другой метод для создания коротких имен файлов для случая, когда имеется пять или более файлов, которые привели бы к двойным коротким именам файла. Для пятого и последующих файлов Windows NT использует только первые два символа от длинного имени файла и далее специальной математической операцией (функция от длинного имени) генерирует следующие уникальные четыре символа короткого имени файла; после этого к результату добавляется ~5 (или другой номер

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

NTFS.

По умолчанию, Windows NT поддерживает имена файлов в формате MS DOS на всех томах NTFS. Для повышения эффективности работы на томах с большим количеством длинных похожих имен можно запретить эту возможность для всех томов. Для отключения поддержки коротких имен файлов на всех томах NTFS необходимо установтъ в 1 значение NTfsDisable8dot3NameCreation следующего элемента реестра:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem.

Windows NT не генерирует коротких имен для файлов, созданных приложениями POSIX в разделе NTFS. Это означает, что приложения MS DOS и Windows З.х не смогут работать с подобными именами, если эти имена не удовлетворяют условию "восемь плюс три". В случае необходимости работы из приложений MS DOS или Windows с файлами, которые созданы приложениями POSIX, следует убедиться, что использованы стандартные имена MS DOS.

Потоки данных

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

Следующий пример иллюстрирует один из потоков:

myfile.dat :stream2

Эта возможность позволяет управлять связанными данными как отдельным модулем. Например, компьютеры Macintosh используют этот тип структуры для управления ветвлениями данных и ресурсами.

Другим примером может служить библиотека файлов, в которой файлы определены как альтернативные потоки:

library: filel

:file2

:file3

Или предположим, что "интеллектуальный" транслятор создает

структуру файла подобно следующей:

program: source_file

:doc_file

:object_file

:executable_file

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

Согласованность с POSIX

Согласованность с POSIX позволяет переносить приложения UNIX в среду Windows NT. Windows NT полностью согласована со стандартом 1003.1 института IEEE, который определяет присвоение имен и идентификацию файлов.

Следующие возможности POSIX включены в NTFS:

-Чувствительные к регистру имена. Для POSIX файлы READ-

ME.TXT, Readme.txt и readme.txt являются различными.

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

-Дополнительные отметки времени. Показывают, когда файл был последний раз использован или изменен.

Несмотря на то что NTFS поддерживает регистрозависимые имена, нельзя использовать стандартные операции NTFS для управления файлами, имена которых отличаются только регистром (к стандартным операциям относятся выполняемые из командной строки, типа copy, del, move и их эквиваленты в File Manager). Например, оба файла annm.doc и AnnM.Doc будут удалены при использовании следующей команды:

del AnnM.Doc

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

Системные файлы NTFS

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

Список системных файлов NTFS представлен в табл.