4.3.4.Файловая система windows 95

В течение долгих лет пользователи 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 обнаружено, что, если у некоторого элемента каталога установлена "нереальная" комбинация битов атрибутов: "только для чтения", "скрытый", "системный", "метка тома" - другими словами, если байту атрибутов некоторого элемента каталога присвоить значение 0FН, - тогда любые функции, имеющиеся во всех существующих версиях DOS и Windows (предшествующих Windows 95), не "заметят" такого элемента каталога, словно его нет.

В итоге для Windows 95 проблема была решена следующим образом: для каждого файла и подкаталога имеются два имени: короткое, "понятное" всем прикладным программам, и длинное - для приложений Windows 95 и тех программ, в которых предусмотрена возможность работы с длинными именами. Для хранения коротких имен в формате 8.3 используются обычные 32-байтовые записи. Короткие имена Windows создает из длинных имен, отсекая шесть старших символов и добавляя в конец этого базового имени "1". Если же существует еще одно имя, состоящее из тех же шести символов, то этот номер увеличивается на единицу. Расширение файла сохраняется прежним. Если в имени встречается символ, не допустимый в предыдущих версиях Windows и DOS, он заменяется на знак "подчеркивание" (_). Длинные имена (LFN) хранятся в специально отформатированных 32-байтовых записях, байт атрибутов у которых равен 0FН. Для конкретного файла или подкаталога непосредственно перед его единственной записью каталога с его именем в формате 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 символа).

Рис. 23. Элемент каталога для длинного имени

В младших пяти битах первого байта записи содержится порядковый номер, указывающий позицию данной записи каталога относительно остальных элементов, представляющих длинное имя данного файла. Например, если для записи длинного имени требуются три элемента каталога, то для первого из них порядковый номер будет равен 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, легко находит его длинное имя. Следующий рисунок иллюстрирует, как бы выглядели элементы каталога для короткого и длинного имени файла, если вместо Bud- get.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, производит упаковку рабочих записей в каталоге, объединяя свободные записи в единую область. Необходимо регулярно проводить дефрагментацию своих дисков, тем более если вы работаете с длинными именами.