Организация информации на жестком диске

      Длинные имена в VFAT. Дополнение операционной системы, работающей с именами файлов формата 8.3, возможностями использования длинных имен файлов не означает лишь просто увеличение размера элементов каталога для размещения более 11 символов, поскольку необходима совместимость и с предыдущими версиями. Если в новой операционной системе записи каталога будут представлены в новом формате, то, переписав файл на гибкий диск под управлением новой системы, будет невозможно прочитать его с помощью старой. Имеется и другая проблема. Если новая операционная система будет передавать старым прикладным системам, рассчитанным на прием имен с длиной не более 11 символов, 255-символьные имена, то будут происходить сбои. В программе для хранения считываемых имен файлов выделяется некоторая область памяти; если для этих целей предусматривается 16 байт, а операционная система пересылает по названному адресу 32 символа, то данные могут быть записаны поверх другой информации. Любой программист может сказать, что наилучший способ навредить программе - записать что-то чужое в ее область данных.

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

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

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

      Если файл с длинным именем записать на гибкий диск, а затем прочитать его на компьютере, работающем под управлением DOS или Windows 3.x, то операционная система распознает лишь короткое имя файла и проигнорирует все записи каталога для длинного имени. А поскольку в данном случае операционная система распознает лишь короткое имя, прикладная программа, запросившая у нее имя файла или подкаталога, не получит неожиданно длинное имя. В Windows 95(98) прикладным программам для 16 разрядных систем DOS и Windows, как и прежде, доступны лишь короткие имена файлов, поскольку в ответ на их запросы операционная система передает имена файлов и подкаталогов в формате 8.3. Чтобы получить длинное имя, программа должна обратиться к системным специальным функциям. Во всех прикладных программах для 32 разрядной версии Windows эти функции вызываются по умолчанию, поэтому они автоматически получают доступ к длинным именам.

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

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

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

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

41 42 00 75 00 64 00 67-00 65 00 0F 00 D8 74 00 A B . u . d . g . e . . . . t .

2E 00 78 00 6C 00 73 00-00 00 00 00 FF FF FF FF . . x . l . s . . . . . . . . .

42 55 44 47 45 54 20 20-58 4C 53 20 00 96 34 87 B U D G E T     X L S   . . 4 .

70 20 70 20 00 00 54 48-70 20 C9 03 A9 1D 00 00 p   p   . . T H p   . . . . . .

Рис.3.8. Шестнадцатеричное представление элементов каталога для файла с именем Budget.xls

43 36 00 2E 00 78 00 6C-00 73 00 0F 00 E0 00 00 C 6 . . . x . l . s . . . . . .

FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF . . . . . . . . . . . . . . . .

02 73 00 63 00 61 00 6C-00 20 00 0F 00 E0 59 00 . s . c . a . l .   . .   . y .

65 00 61 00 72 00 20 00-31 00 00 00 39 00 39 00 e . a . r .   . 1 . . . 9 . 9 .

01 42 00 75 00 64 00 67-00 65 00 0F 00 D8 74 00 . B . u . d . g . e . . . . t .

20 00 66 00 6F 00 72 00-20 00 00 00 46 00 69 00 . f . o . r .   . . . . F . i .

42 55 44 47 45 54 7E 31-58 4C 53 20 00 4A CF 88 B U D G E T ~ 1 X L S   . J . .

70 20 70 20 00 00 54 48-70 20 C9 03 A9 1D 00 00 p   p   . . T H p   . . . . . .

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

Рис.3.9. Шестнадцатеричное представление элементов каталога для файла с именем              Budget for Fiscal Year 1996.xls

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

      Одна из проблем, присущих использованию длинных имен, заключается в том, что для них требуется больше дискового пространства, чем для коротких имен. Это не имеет существенного значения при хранении длинных имен в подчиненных каталогах, поскольку по мере добавления в каталоги новых записей последние могут расширяться. Однако максимальное число записей в корневом каталоге ограниченно, а длинные имена файлов занимают в нем страшно много места. Для большинства жестких дисков в корневом каталоге может содержаться не более 512 записей. Например, для хранения имени из 128 символов потребуется 11 записей (десять для длинного имени и один - для короткого). Поэтому в корневом каталоге удастся разместить лишь 46 файлов и подкаталогов, если название каждого из них состоит из 128 символов. При использовании длинных имен файлов в корневых каталогах дисков, отформатированных для более совершенных файловых систем, таких, как FAT32, HPFS в OS/2 или NTFS в Windows NT, подобной проблемы не возникает, поскольку размер корневых каталогов в них не ограничен.

      Более серьезная проблема возникает в том случае, когда элементы каталога длинных имен теряются. Допустим, был переписан некоторый файл на гибкий диск, а затем с ним работали на компьютере под управлением DOS или Windows 3.1. Если там удалить или переименовать этот файл, то будет удалена или переименована соответствующая запись для формата 8.3. Однако записи для длинных имен останутся нетронутыми, поскольку ни DOS, ни Windows 3.1 не подозревают об их существовании. Такие записи оказываются потерянными. (Конечно, аналогичные потерянные записи для длинных имен могут образоваться и на жестком диске, если загрузить систему с дискеты, где содержится DOS, и удалить или переименовать файлы на жестком диске.)

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

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

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

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