Дизайн файловой системы FAT

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

Файловая система FAT - это устаревшая файловая система, простая и надежная. ^[3] Он предлагает хорошую производительность даже в очень легких реализациях, но не может обеспечить такую ​​же производительность, надежность и масштабируемость, как некоторые современные файловые системы. Тем не менее, он поддерживается по соображениям совместимости почти всеми разрабатываемыми в настоящее время операционными системами для персональных компьютеров и многих домашних компьютеров , мобильных устройств и встроенных систем и, таким образом, является хорошо подходящим форматом для обмена данными между компьютерами и устройствами практически любого типа и возраста. с 1981 года по настоящее время.

Первоначально разработанная в 1977 году для использования на гибких дисках , FAT вскоре была адаптирована и использовалась почти повсеместно на жестких дисках в эпоху DOS и Windows 9x в течение двух десятилетий. Сегодня файловые системы FAT по-прежнему широко используются на гибких дисках, USB-накопителях , флэш- дисках и других твердотельных картах и модулях памяти , а также на многих портативных и встроенных устройствах. DCF реализует FAT в качестве стандартной файловой системы для цифровых камер с 1998 года. ^[4] FAT также используется для системного раздела EFI (тип раздела 0xEF ) на этапе загрузкиEFI- совместимые компьютеры.

Для гибких дисков FAT стандартизирован как ECMA- 107 ^[5] и ISO / IEC  9293: 1994 ^[6] (заменяющий ISO 9293: 1987 ^[7] ). Эти стандарты охватывают FAT12 и FAT16 с поддержкой только коротких файлов 8.3 ; длинные имена файлов с VFAT являются частично запатентованы . ^[8] Согласно патентам Google, статус «Общее пространство имен для длинных и коротких имен файлов» (US5758352A) истек в 2019 году, что может означать, что срок действия патента истек полностью. ^[9]

Технический обзор [ править ]

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

Первоначально разработанная как 8-битная файловая система, максимальное количество кластеров было значительно увеличено по мере развития дисковых накопителей, и поэтому количество битов, используемых для идентификации каждого кластера, увеличилось. Последовательные основные версии формата FAT названы по количеству битов элемента таблицы: 12 ( FAT12 ), 16 ( FAT16 ) и 32 ( FAT32 ). За исключением исходного 8-битного предшественника FAT , каждый из этих вариантов все еще используется. Стандарт FAT также был расширен другими способами, при этом в целом сохранена обратная совместимость с существующим программным обеспечением.

Макет [ править ]

Файловая система FAT состоит из четырех областей:

Зарезервированные секторы

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

Важная информация из загрузочного сектора доступна через структуру операционной системы, называемую блоком параметров диска ( DPB ) в DOS и OS / 2.

Общее количество зарезервированных секторов указано в поле внутри загрузочного сектора и обычно составляет 32 в файловых системах FAT32. ^[10]

Для файловых систем FAT32 зарезервированные секторы включают в себя информационный сектор файловой системы в логическом секторе 1 и резервный загрузочный сектор в логическом секторе 6.

В то время как многие другие поставщики продолжали использовать односекторную настройку (только логический сектор 0) для загрузчика начальной загрузки, код загрузочного сектора Microsoft с момента введения FAT32 расширился и теперь охватывает логические сектора 0 и 2, причем логический сектор 0 зависит от подпрограммы в логическом секторе 2. Область резервного загрузочного сектора также состоит из трех логических секторов 6, 7 и 8. В некоторых случаях Microsoft также использует сектор 12 области зарезервированных секторов для расширенного загрузчика.

FAT Регион

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

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

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

Первые два кластера (кластер 0 и 1 ) на карте содержат специальные значения.

Регион корневого каталога

Это таблица каталогов, в которой хранится информация о файлах и каталогах, расположенных в корневом каталоге. Он используется только с FAT12 и FAT16 и налагает на корневой каталог фиксированный максимальный размер, который предварительно выделяется при создании этого тома. FAT32 хранит корневой каталог в области данных вместе с файлами и другими каталогами, что позволяет ему расти без таких ограничений. Таким образом, для FAT32 область данных начинается здесь.

Область данных

Здесь хранятся фактические данные файла и каталога, которые занимают большую часть раздела. Традиционно неиспользуемые части области данных инициализируются значением заполнения 0xF6 в соответствии с таблицей параметров диска INT 1Eh (DPT) во время форматирования на IBM-совместимых машинах, но также используются в Atari Portfolio . 8-дюймовые дискеты CP / M обычно поставлялись предварительно отформатированными со значением 0xE5 ; ^[11] посредством Digital Research ^[12] это значение также использовалось на дискетах формата Atari ST . ^{[NB 1]} Amstrad использовали 0xF4 вместо этого. Некоторые современные форматеры стирают жесткие диски со значением 0x00 , тогда как значение 0xFF , значение по умолчанию для незапрограммированного блока флэш-памяти, используется на флэш-дисках для уменьшения износа . Последнее значение обычно также используется на дисках ROM. (Некоторые расширенные инструменты форматирования позволяют настроить байт-заполнитель формата. ^{[Nb 2]} )

Размер файлов и подкаталогов можно произвольно увеличивать (до тех пор, пока есть свободные кластеры), просто добавляя дополнительные ссылки в цепочку файлов в FAT. Файлы распределяются в единицах кластеров, поэтому, если файл размером 1 КБ находится в кластере 32 КБ , 31 КБ теряется.

FAT32 обычно начинает таблицу корневого каталога в кластере номер 2: первом кластере области данных.

FAT использует формат с прямым порядком байтов для всех записей в заголовке (за исключением, если это явно указано, для некоторых записей в загрузочных секторах Atari ST) и FAT (ов). ^[12]Можно выделить больше секторов FAT, чем необходимо для количества кластеров. Конец последнего сектора каждой копии FAT может не использоваться, если нет соответствующих кластеров. Общее количество секторов (как указано в загрузочной записи) может быть больше, чем количество секторов, используемых данными (кластеры × секторы на кластер), FAT (количество FAT × секторов на FAT), корневой каталог (n / a для FAT32) и скрытых секторов, включая загрузочный сектор: это приведет к появлению неиспользуемых секторов в конце тома. Если раздел содержит больше секторов, чем общее количество секторов, занятых файловой системой, это также приведет к появлению неиспользуемых секторов в конце раздела после тома.

Область зарезервированных секторов [ править ]

Загрузочный сектор [ править ]

На устройствах без разделов, таких как дискеты , загрузочный сектор ( VBR ) является первым сектором (логический сектор 0 с физическим адресом CHS 0/0/1 или адресом LBA 0). Для разделенных на разделы устройств, таких как жесткие диски, первый сектор является главной загрузочной записью, определяющей разделы, а первый сектор разделов, отформатированных с файловой системой FAT, снова является загрузочным сектором.

Общая структура первых 11 байтов, используемых большинством версий FAT для IBM-совместимых x86-машин, начиная с DOS 2.0:

Дискеты Atari ST в формате FAT имеют очень похожую структуру загрузочного сектора:

Тома MSX-DOS в формате FAT12 имеют очень похожую структуру загрузочного сектора:

Блок параметров BIOS [ править ]

Общая структура первых 25 байтов блока параметров BIOS (BPB), используемых версиями FAT, начиная с DOS 2.0 (байты со смещением сектора от 0x00B до 0x017 сохраняются с DOS 2.0, но не всегда используются до DOS 3.2, значения от 0x018 до 0x01B являются используется с DOS 3.0):

DOS 3.0 BPB:

Следующие расширения были задокументированы, начиная с DOS 3.0, однако они уже поддерживались некоторыми выпусками DOS 2.11. ^[32] MS-DOS 3.10 по-прежнему поддерживает формат DOS 2.0, но может также использовать формат DOS 3.0.

DOS 3.2 BPB:

Официально MS-DOS 3.20 еще используется формат DOS 3.0, но SYSи FORMATбыли приспособлены для поддержки 6 байт длиннее формат уже (из которых были использованы не все записи).

DOS 3.31 BPB:

Официально представленные в DOS 3.31 и не используемые в DOS 3.2, некоторые утилиты DOS 3.2 были разработаны с учетом этого нового формата. Официальная документация рекомендует доверять этим значениям только в том случае, если запись логических секторов по смещению 0x013 равна нулю.

Простая формула переводит заданный номер кластера тома CNв логический номер сектора LSN: ^{[5] [6] [7]}

1. Определите (один раз) , где счетчик зарезервированных секторов хранится по смещению 0x00E , количество FAT по смещению 0x010 , секторов на FAT по смещению 0x016 (FAT12 / FAT16) или 0x024 (FAT32), записи корневого каталога по смещению 0x011 , размер сектора по смещению 0x00B и округляется до целого числа.SSA=RSC+FN×SF+ceil((32×RDE)/SS)RSCFNSFRDESSceil(x)
2. Определите , где хранятся сектора в кластере по смещению 0x00D .LSN=SSA+(CN−2)×SCSC

На неразмеченных СМИ номер тома скрытых секторов равно нуль , и , следовательно , LSNи LBAадреса становятся такими же , так долго , как размер логического сектора тома идентичен размером физического сектора подстилающего медиума. В этих условиях также легко переводить между CHSадресами, LSNsа также:

LSN=SPT×(HN+(NOS×TN))+SN−1, где секторы на дорожку SPTхранятся со смещением 0x018 , а количество сторон - со смещением 0x01A . Номер дорожки, номер головки и номер сектора соответствуют сектору головки цилиндра : формула дает известное преобразование CHS в LBA .NOSTNHNSN

Блок расширенных параметров BIOS [ править ]

Дополнительная структура, используемая FAT12 и FAT16 начиная с OS / 2 1.0 и DOS 4.0, также известная как расширенный блок параметров BIOS (EBPB) (байты ниже смещения сектора 0x024 такие же, как для DOS 3.31 BPB):

Блок расширенных параметров BIOS FAT32 [ править ]

По сути, FAT32 вставляет 28 байтов в EBPB, за которыми следуют оставшиеся 26 (а иногда только 7) байтов EBPB, как показано выше для FAT12 и FAT16. Операционные системы Microsoft и IBM определяют тип файловой системы FAT, используемой на томе, исключительно по количеству кластеров, а не по используемому формату BPB или указанному типу файловой системы, то есть технически возможно использовать «FAT32 EBPB» также для томов FAT12 и FAT16, а также EBPB DOS 4.0 для небольших томов FAT32. Поскольку было обнаружено, что такие тома создаются операционными системами Windows при некоторых странных условиях, операционные системы ^{[nb 8]} должны быть готовы к работе с этими гибридными формами.

Исключения [ править ]

Версии DOS до 3.2 полностью или частично полагались на байт дескриптора носителя в BPB или байт идентификатора FAT в кластере 0 первой FAT для определения форматов дискет FAT12, даже если присутствует BPB. В зависимости от найденного FAT ID и обнаруженного типа диска они по умолчанию используют один из следующих прототипов BPB вместо значений, фактически хранящихся в BPB. ^{[№ 3]}

Первоначально FAT ID должен был быть битовым флагом со всеми установленными битами, за исключением бита 2, очищенного для указания формата 80 дорожек (против 40 дорожек), бит 1 очищен, чтобы указать формат 9 секторов (против 8 секторов), и бит 0 очищен для обозначения одностороннего (по сравнению с двусторонним) формата ^[14], но эта схема не соблюдалась всеми OEM-производителями и устарела с появлением жестких дисков и форматов высокой плотности. Кроме того, различные 8-дюймовые форматы, поддерживаемые 86-DOS и MS-DOS, не подходят для этой схемы.

Microsoft рекомендует различать два 8-дюймовых формата для FAT ID 0xFE , пытаясь прочитать адресную метку с одинарной плотностью. Если это приводит к ошибке, среда должна быть двойной плотности. ^[30]

В таблице не указан ряд несовместимых форматов 8-дюймовых и 5,25-дюймовых гибких дисков FAT12, поддерживаемых 86-DOS , которые различаются либо размером записей каталога (16 байтов против 32 байтов), либо размером зарезервированного область секторов (несколько целых дорожек против только одного логического сектора).

Реализация одностороннего формата FAT12 размером 315 КБ, используемого в MS-DOS для ПК Apricot и F1e ^[38], имела разную компоновку загрузочного сектора для соответствия BIOS этого компьютера, несовместимого с IBM. Команда перехода и имя OEM были опущены, а параметры BPB MS-DOS (смещения 0x00B - 0x017 в стандартном загрузочном секторе) были расположены по смещению 0x050 . Портативное , F1 , дуэт ПК и Си FD поддерживают нестандартный двухсторонние 720 КБ формата FAT12 вместо этого. ^[38]Различия в макете загрузочного сектора и идентификаторах носителей сделали эти форматы несовместимыми со многими другими операционными системами. Параметры геометрии для этих форматов:

• 315 КБ: байтов на логический сектор: 512 байтов, логических секторов на кластер: 1, зарезервированных логических секторов: 1, количество файлов FAT: 2, записей корневого каталога: 128, всего логических секторов: 630, идентификатор FAT: 0xFC , логических секторов на FAT: 2, физических секторов на дорожку: 9, количество головок: 1. ^{[38] [39]}
• 720 КБ: байтов на логический сектор: 512 байтов, логических секторов на кластер: 2, зарезервированных логических секторов: 1, количество файлов FAT: 2, записей корневого каталога: 176, всего логических секторов: 1440, FAT ID: 0xFE , логических секторов на FAT: 3, физических секторов на дорожку: 9, количество головок: 2. ^[38]

В более поздних версиях Apricot MS-DOS появилась возможность читать и записывать диски со стандартным загрузочным сектором в дополнение к дискам с Apricot. Эти форматы также поддерживались DOS Plus 2.1e / g для серии Apricot ACT.

Адаптация DOS Plus для BBC Master 512 поддерживала два формата FAT12 на 80-дорожечных двусторонних 5,25-дюймовых накопителях с двойной плотностью, которые вообще не использовали обычные загрузочные секторы. На дисках данных 800 КБ не был загрузочный сектор, и они начинались с единственная копия FAT. ^[39] Для определения емкости диска использовался первый байт перемещенной FAT в логическом секторе 0. Загрузочные диски размером 640 КБ начинались с миниатюрной файловой системы ADFS, содержащей загрузчик, за которой следовала единственная файловая система FAT . ^{[39] [40]} Кроме того, формат 640 КБ отличался использованием физических номеров секторов CHS, начинающихся с 0 (а не 1, как обычно), и увеличения секторов в порядке сектор-заголовок (не сектор-заголовок-дорожка, как общий). ^[40]FAT стартовал в начале следующего трека. Эти различия делают эти форматы нераспознаваемыми другими операционными системами. Параметры геометрии для этих форматов:

• 800 КБ: байтов на логический сектор: 1024 байта, логических секторов на кластер: 1, зарезервированных логических секторов: 0, количество FAT: 1, записей корневого каталога: 192, всего логических секторов: 800, FAT ID: 0xFD , логических секторов на FAT: 2, физических секторов на дорожку: 5, количество головок: 2. ^{[39] [40]}
• 640 КБ: байтов на логический сектор: 256 байтов, логических секторов на кластер: 8, зарезервированных логических секторов: 16, количество файлов FAT: 1, записей корневого каталога: 112, всего логических секторов: 2560, FAT ID: 0xFF , логических секторов на FAT: 2, физических секторов на дорожку: 16, количество головок: 2. ^{[39] [40]}

DOS Plus для Master 512 может также получить доступ к стандартным дискам ПК, отформатированным до 180 или 360 КБ , используя первый байт FAT в логическом секторе 1 для определения емкости.

DEC Rainbow 100 (все варианты) поддерживает один формат FAT12 на 80-дорожечных односторонних 5,25-дюймовых накопителях с четырехканальной плотностью. Первые две дорожки были зарезервированы для загрузчика, но не содержали MBR или BPB ( MS-DOS вместо этого использовала статический BPB в памяти). Загрузочный сектор (дорожка 0, сторона 0, сектор 1) представлял собой код Z80, начинающийся с DI 0xF3 . Загрузочная программа 8088 была загружена Z80. Дорожка 1, сторона 0, сектор 2 начинается с байта идентификатора Media / FAT 0xFA . Неформатированные диски используют 0xE5.вместо. Файловая система начинается на дорожке 2, сторона 0, сектор 1. В корневом каталоге есть 2 копии FAT и 96 записей. Кроме того, существует отображение физических и логических дорожек для осуществления перемежения секторов 2: 1. Диски были отформатированы с физическими секторами в порядке пронумерованных от 1 до 10 на каждой дорожке после зарезервированных дорожек, но логические сектора от 1 до 10 были сохранены в физических секторах 1, 6, 2, 7, 3, 8, 4, 9. , 5, 10. ^[41]

Информационный сектор ФС [ править ]

«Информационный сектор FS» был введен в FAT32 ^[42] для ускорения времени доступа к определенным операциям (в частности, для получения количества свободного места). Он расположен в номере логического сектора, указанного в загрузочной записи FAT32 EBPB в позиции 0x030 (обычно логический сектор 1, сразу после самой загрузочной записи).

Данные сектора могут быть устаревшими и не отражать текущее содержимое мультимедиа, потому что не все операционные системы обновляют или используют этот сектор, и даже если они это делают, содержимое недействительно, когда носитель был извлечен без надлежащего размонтирования тома или после сбой питания. Следовательно, операционные системы должны сначала проверить дополнительные битовые флаги состояния выключения тома, находящиеся в записи FAT кластера 1 или FAT32 EBPB по смещению 0x041, и игнорировать данные, хранящиеся в информационном секторе FS, если эти битовые флаги указывают, что том не был правильно размонтирован. перед. Это не вызывает никаких проблем, кроме возможного снижения скорости для первого запроса свободного пространства или выделения кластера данных; увидеть фрагментацию .

Если этот сектор присутствует на томе FAT32, минимально допустимый размер логического сектора составляет 512 байтов, тогда как в противном случае он был бы 128 байтов. Некоторые реализации FAT32 поддерживают небольшую вариацию спецификации Microsoft, делая информационный сектор FS необязательным путем указания значения 0xFFFF ^[26] (или 0x0000 ) в записи со смещением 0x030 .

Таблица размещения файлов [ править ]

Карта кластера [ править ]

Область данных тома разделена на кластеры одинакового размера - небольшие блоки непрерывного пространства. Размеры кластера различаются в зависимости от типа используемой файловой системы FAT и размера раздела; типичный размер кластера составляет от 2 до 32 КБ . ^{[ необходима цитата ]}

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

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

FAT12 файловая система использует 12 бит на входе FAT, таким образом , две записи охватывают 3 байта. Он последовательно является прямым порядком байтов : если эти три байта рассматриваются как одно 24-битное число с прямым порядком байтов, 12 младших битов представляют первую запись (например, кластер 0), а 12 старших битов - вторую (например, кластер 1). . Другими словами, в то время как младшие восемь бит первого кластера в строке хранятся в первом байте, верхние четыре бита хранятся в младшем полубайте второго байта, тогда как младшие четыре бита последующего кластера в строке хранятся в старшем полубайте второго байта и его старших восьми битах в третьем байте.

FAT16 файловой система использует 16 бит на вход FAT, таким образом , один ввод занимает два байта в обратном порядке байт:

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

Таблица размещения файлов ( FAT ) представляет собой непрерывный ряд секторов сразу после зоны зарезервированных секторов. Он представляет собой список записей, которые сопоставляются каждому кластеру тома. Каждая запись записывает одну из пяти вещей:

• номер следующего кластера в цепочке
• запись о конце цепочки кластера ( EOC ), которая указывает конец цепочки
• специальная запись, чтобы отметить плохой кластер
• ноль, чтобы отметить, что кластер не используется

Для очень ранних версий DOS, чтобы распознать файловую систему, система должна быть загружена с тома или FAT тома должна начинаться со второго сектора тома (логический сектор 1 с физическим адресом CHS 0/0/2 или адресом LBA 1) , то есть сразу после загрузочного сектора. Операционные системы предполагают, что это жестко привязанное расположение FAT, чтобы найти идентификатор FAT в записи кластера 0 FAT на дискетах с DOS 1.0-1.1 FAT, где не найдено действительных BPB.

Особые записи [ править ]

Первые две записи в FAT хранят специальные значения:

Первая запись (кластер 0 в FAT) содержит идентификатор FAT, начиная с MS-DOS 1.20 и PC DOS 1.1 (допустимые значения 0xF0 - 0xFF с 0xF1 - 0xF7 зарезервированы) в битах 7-0, который также копируется в BPB файла загрузочный сектор, смещение 0x015 начиная с DOS 2.0. Оставшиеся 4 бита (для FAT12), 8 бит (для FAT16) или 20 бит (для FAT32) этой записи всегда равны 1. Эти значения были организованы таким образом, чтобы запись также функционировала как «перехватчик всех» в конце записи. -chain маркер для всех кластеров данных, содержащих нулевое значение. Кроме того, для идентификаторов FAT, отличных от 0xFF (и 0x00) можно определить правильный порядок полубайтов и байтов (который будет использоваться) драйвером файловой системы, однако файловая система FAT официально использует только прямое представление, и нет известных реализаций вариантов, использующих значения с прямым порядком байтов. вместо. 86-DOS 0.42 до MS-DOS 1.14 использовали профили жестких дисков вместо FAT ID, но использовали этот байт, чтобы различать носители, отформатированные с 32-байтовыми или 16-байтовыми записями каталога, поскольку они использовались до 86- ДОС 0.42.

Вторая запись (кластер 1 в FAT) номинально хранит маркер конца цепочки кластера, используемый форматером, но обычно всегда содержит 0xFFF / 0xFFFF / 0x0FFFFFFF , то есть, за исключением битов 31-28 в FAT32. Обычно эти биты устанавливаются всегда. Однако некоторые операционные системы Microsoft устанавливают эти биты, если том не является томом, содержащим работающую операционную систему (то есть здесь используется 0xFFFFFFFF вместо 0x0FFFFFFF ). ^[43] (В сочетании с альтернативными маркерами конца цепочки младшие биты 2-0 могут стать нулевыми для самого низкого разрешенного маркера конца цепочки 0xFF8 / 0xFFF8 / 0x? FFFFFF8; бит 3 также должен быть зарезервирован, учитывая, что кластеры 0xFF0 / 0xFFF0 / 0x? FFFFFF0 и выше официально зарезервированы. Некоторые операционные системы могут не иметь возможности монтировать некоторые тома, если какой-либо из этих битов не установлен, поэтому маркер конца цепочки по умолчанию не следует изменять.) Для DOS 1 и 2 запись была задокументирована как зарезервированная для использования в будущем. .

Начиная с DOS 7.1, два наиболее значимых бита этой записи кластера могут содержать два необязательных битовых флага, представляющих текущий статус тома в FAT16 и FAT32, но не в томах FAT12. Эти битовые флаги поддерживаются не всеми операционными системами, но операционные системы, поддерживающие эту функцию, будут устанавливать эти биты при завершении работы и сбрасывать наиболее значимый бит при запуске:
если бит 15 (в FAT16) или бит 27 (в FAT32) ^[44] не установлен. установленный при монтировании тома, том не был должным образом размонтирован перед выключением или извлечением и, таким образом, находится в неизвестном и, возможно, «грязном» состоянии. ^[31] На томах FAT32 информационный сектор FS может содержать устаревшие данные, поэтому его не следует использовать. В этом случае операционная система обычно запускает SCANDISK илиCHKDSK при следующем запуске ^{[nb 10] [44]} (но не при вставке съемного носителя), чтобы гарантировать и, возможно, восстановить целостность тома.
Если бит 14 (в FAT16) или бит 26 (в FAT32) ^[44] очищен, операционная система обнаружила ошибки дискового ввода-вывода при запуске ^[44], что может указывать на наличие сбойных секторов. Операционные системы, знающие об этом расширении, будут интерпретировать это как рекомендацию выполнить сканирование поверхности ( SCANDISK ) при следующей загрузке. ^{[31] [44]} (Аналогичный набор битовых флагов существует в FAT12 / FAT16 EBPB со смещением 0x1A или в FAT32 EBPB со смещением 0x36. Хотя запись кластера 1 может быть доступна драйверам файловой системы после того, как они смонтировали том, запись EBPB доступна, даже если том не смонтирован, и, таким образом, ее проще использовать драйверам блочных устройств диска или инструментам разделения.)

Если количество жиров в ВРВЕ не установлено в положении 2, второй элемент кластера в первой FAT (кластер 1) может также отражать статус TFAT объема для TFAT-осведомленных операционные систем. Если запись кластера 1 в этой FAT содержит значение 0, это может означать, что вторая FAT представляет последнее известное действительное состояние транзакции и должна быть скопирована поверх первой FAT, тогда как первая FAT должна быть скопирована поверх второй FAT, если все биты установлены.

Некоторые нестандартные реализации FAT12 / FAT16 используют запись кластера 1 для хранения начального кластера корневого каталога переменного размера (обычно 2 ^[37] ). Это может произойти, если количество записей корневого каталога в BPB имеет значение 0, а FAT32 EBPB не найден (нет подписи 0x29 или 0x28 по смещению 0x042 ). ^[27] Это расширение, однако, не поддерживается основными операционными системами, ^{[27] так} как оно противоречит другим возможным применениям записи кластера 1. Большинство конфликтов можно исключить, если это расширение разрешено только для FAT12 с менее 0xFEF и FAT16 с менее чем 0x3FEF. кластеры и 2 FAT.

Поскольку эти первые две записи FAT хранят специальные значения, нет кластеров данных 0 или 1. Первым кластером данных (после корневого каталога, если FAT12 / FAT16) является кластер 2, ^[37] обозначающий начало области данных.

Значения кластера [ править ]

Значения записи FAT:

Несмотря на свое название, FAT32 использует только 28 бит из 32 возможных. Старшие 4 бита обычно равны нулю, но они зарезервированы и их не следует трогать. Стандартный совместимый драйвер файловой системы FAT32 или инструмент обслуживания не должен полагаться на то, что верхние 4 бита равны нулю, и он должен удалить их перед оценкой номера кластера, чтобы справиться с возможными будущими расширениями, где эти биты могут использоваться для других целей. Они не должны очищаться драйвером файловой системы при выделении новых кластеров, но должны очищаться во время переформатирования.

Ограничения по размеру [ править ]

Варианты FAT12, FAT16, FAT16B и FAT32 файловых систем FAT имеют четкие ограничения, основанные на количестве кластеров и количестве секторов в кластере (1, 2, 4, ..., 128). Для типичного значения 512 байт на сектор:

Требования FAT12: 3 сектора на каждую копию FAT на каждые 1024 кластера
Требования FAT16: 1 сектор на каждую копию FAT на каждые 256 кластеров
Требования FAT32: 1 сектор на каждую копию FAT на каждые 128 кластеров

Диапазон FAT12: от 1 до 4084 кластера:
От 1 до 12 секторов на копию FAT Диапазон FAT16: от 4085 до 65 524 кластеров: от 16 до 256 секторов на копию FAT
Диапазон FAT32: от 65 525 до 268 435 444 кластера: от 512 до 2097 152 секторов на копию FAT

FAT12 минимум: 1 сектор на кластер × 1 кластер = 512 байт (0,5 КБ)
Минимум FAT16: 1 сектор на кластер × 4085 кластеров = 2 091 520 байт (2042,5 КБ)
Минимум FAT32: 1 сектор на кластер × 65 525 кластеров = 33 548 800 байт (32 762,5 КБ)

Максимум FAT12: 64 сектора на кластер × 4084 кластера = 133824512 байтов (≈ 127 МБ)
[максимум FAT12: 128 секторов на кластер × 4084 кластера = 267 694 024 байта (≈ 255 МБ)]

Максимум FAT16: 64 сектора на кластер × 65 524 кластера = 2147 090 432 байтов (≈ 2047 МБ)
[максимум FAT16: 128 секторов на кластер × 65 524 кластера = 4294 180 864 байта (≈ 4095 МБ)]

Максимум FAT32: 8 секторов на кластер × 268 435 444 кластера = 1099 511 578 624 байта (≈1 024 ГБ)
Максимум FAT32: 16 секторов на кластер × 268 173 557 кластеров = 2 196 877 778 944 байта (≈ 2046 ГБ)
[максимум FAT32: 32 сектора на кластер × 134 152 181 кластер = 2 197 949 333 504 байта (≈ 2047 ГБ)]
[Максимум FAT32: 64 сектора на кластер × 67 092 469 кластеров = 2 198 486 024 192 байта (≈ 2047 ГБ)]
[Максимум FAT32: 128 секторов на кластер × 33 550 325 кластеров = 2 198 754 099 200 байт (≈ 2047 ГБ)]

Обозначения: 268435444 + 3 - 0x0FFFFFF7 , потому что FAT32 версии 0 использует только 28 битов в 32-битных номерах кластеров, номера кластеров от 0x0FFFFFF7 до 0x0FFFFFFF указывают на плохие кластеры или конец файла, номер кластера 0 отмечает свободный кластер и кластер номер 1 не используется. ^[37] Аналогично, 65524 + 3 - это 0xFFF7 для FAT16, а 4084 + 3 - 0xFF7 для FAT12. Количество секторов в кластере представляет собой степень двойки, подходящую для одного байта, наименьшее значение - 1 ( 0x01 ), наибольшее значение - 128 ( 0x80 ). Строки в квадратных скобках указывают на необычный размер кластера 128, а для FAT32 размер кластера больше необходимого 32 или 64. ^[48]

Поскольку каждая запись FAT32 занимает 32 бита (4 байта), максимальное количество кластеров (268435444) требует 2097152 сектора FAT для размера сектора 512 байтов. 2097152 - это 0x200000 , и для хранения этого значения требуется более двух байтов. Следовательно, FAT32 представила новое 32-битное значение в загрузочном секторе FAT32 сразу после 32-битного значения для общего количества секторов, представленных в варианте FAT16B.

Расширения загрузочной записи, представленные в DOS 4.0, начинаются с магического 40 ( 0x28 ) или 41 ( 0x29 ). Обычно драйверы FAT смотрят только на количество кластеров, чтобы различать FAT12, FAT16 и FAT32: удобочитаемые строки, идентифицирующие вариант FAT в загрузочной записи, игнорируются, поскольку они существуют только для носителей, отформатированных с помощью DOS 4.0 или более поздних версий.

Определить количество записей каталога на кластер несложно. Каждая запись занимает 32 байта; в результате получается 16 записей на сектор при размере сектора 512 байт. Команда DOS 5 RMDIR/ RDудаляет начальные записи « .» (этот каталог) и « ..» (родительский каталог) в подкаталогах напрямую, поэтому размер сектора 32 на RAM-диске возможен для FAT12, но требует 2 или более секторов на кластер. Загрузочному сектору FAT12 без расширений DOS 4 требуется 29 байтов до первого ненужного 32-разрядного числа скрытых секторов FAT16B , это оставляет три байта для (на неиспользуемом RAM-диске) загрузочный код и магический 0x55 0xAA в конце всего. загрузочные секторы. В Windows NT минимальный поддерживаемый размер сектора - 128.

В операционных системах Windows NT параметры FORMATкоманды /A:128Kи /A:256Kсоответствуют максимальному размеру кластера 0x80(128) с размером сектора 1024 и 2048 соответственно. Для общего размера сектора 512 /A:64Kполучается 128 секторов на кластер.

Обе редакции каждого ECMA-107 ^[5] и ISO / IEC 9293 ^{[6] [7]} указывают максимальное количество кластеров, MAX определяемое формулой , и зарезервированные номера кластеров до 4086 ( 0xFF6 , FAT12) и более поздних 65526 ​​( 0xFFF6 , FAT16). ) для будущей стандартизации.MAX=1+trunc((TS-SSA)/SC)MAX+1

Спецификация Microsoft EFI FAT32 ^[10] утверждает, что любая файловая система FAT с менее чем 4085 кластерами - это FAT12, в противном случае любая файловая система FAT с менее чем 65525 кластерами - это FAT16, а в противном случае - FAT32. Запись для кластера 0 в начале FAT должна быть идентична байту дескриптора носителя, найденному в BPB, тогда как запись для кластера 1 отражает значение конца цепочки, используемое программой форматирования для цепочек кластеров ( 0xFFF , 0xFFFF или 0x0FFFFFFF ). Записи для номеров кластеров 0 и 1 заканчиваются на границе байта даже для FAT12, например, 0xF9FFFF для дескриптора мультимедиа 0xF9 .

Первый кластер данных - 2, ^[37] и, следовательно, последний кластер MAXполучает номер MAX+1. Это приводит к номерам кластеров данных 2 ... 4085 ( 0xFF5 ) для FAT12, 2 ... 65525 ( 0xFFF5 ) для FAT16 и 2 ... 268435445 ( 0x0FFFFFF5 ) для FAT32.

Поэтому единственными доступными значениями, зарезервированными для будущей стандартизации, являются 0xFF6 (FAT12) и 0xFFF6 (FAT16). Как указано ниже, «менее 4085» также используется для реализаций Linux ^[46] или, как указано в спецификации Microsoft FAT: ^[10]

...when it says <, it does not mean <=. Note also that the numbers are correct. The first number for FAT12 is 4085; the second number for FAT16 is 65525. These numbers and the "<" signs are not wrong.

Fragmentation[edit]

The FAT file system does not contain built-in mechanisms which prevent newly written files from becoming scattered across the partition.^[49] On volumes where files are created and deleted frequently or their lengths often changed, the medium will become increasingly fragmented over time.

While the design of the FAT file system does not cause any organizational overhead in disk structures or reduce the amount of free storage space with increased amounts of fragmentation, as it occurs with external fragmentation, the time required to read and write fragmented files will increase as the operating system will have to follow the cluster chains in the FAT (with parts having to be loaded into memory first in particular on large volumes) and read the corresponding data physically scattered over the whole medium reducing chances for the low-level block device driver to perform multi-sector disk I/O or initiate larger DMA transfers, thereby effectively increasing I/O protocol overhead as well as arm movement and head settle times inside the disk drive. Also, file operations will become slower with growing fragmentation as it takes increasingly longer for the operating system to find files or free clusters.

Other file systems, e.g., HPFS or exFAT, use free space bitmaps that indicate used and available clusters, which could then be quickly looked up in order to find free contiguous areas. Another solution is the linkage of all free clusters into one or more lists (as is done in Unix file systems). Instead, the FAT has to be scanned as an array to find free clusters, which can lead to performance penalties with large disks.

In fact, seeking for files in large subdirectories or computing the free disk space on FAT volumes is one of the most resource intensive operations, as it requires reading the directory tables or even the entire FAT linearly. Since the total amount of clusters and the size of their entries in the FAT was still small on FAT12 and FAT16 volumes, this could still be tolerated on FAT12 and FAT16 volumes most of the time, considering that the introduction of more sophisticated disk structures would have also increased the complexity and memory footprint of real-mode operating systems with their minimum total memory requirements of 128 KB or less (such as with DOS) for which FAT has been designed and optimized originally.

With the introduction of FAT32, long seek and scan times became more apparent, particularly on very large volumes. A possible justification suggested by Microsoft's Raymond Chen for limiting the maximum size of FAT32 partitions created on Windows was the time required to perform a "DIR" operation, which always displays the free disk space as the last line.^[50] Displaying this line took longer and longer as the number of clusters increased. FAT32 therefore introduced a special file system information sector where the previously computed amount of free space is preserved over power cycles, so that the free space counter needs to be recalculated only when a removable FAT32 formatted medium gets ejected without first unmounting it or if the system is switched off without properly shutting down the operating system, a problem mostly visible with pre-ATX-style PCs, on plain DOS systems and some battery-powered consumer products.

With the huge cluster sizes (16 KB, 32 KB, 64 KB) forced by larger FAT partitions, internal fragmentation in form of disk space waste by file slack due to cluster overhang (as files are rarely exact multiples of cluster size) starts to be a problem as well, especially when there are a great many small files.

Various optimizations and tweaks to the implementation of FAT file system drivers, block device drivers and disk tools have been devised to overcome most of the performance bottlenecks in the file system's inherent design without having to change the layout of the on-disk structures.^[51][52] They can be divided into on-line and off-line methods and work by trying to avoid fragmentation in the file system in the first place, deploying methods to better cope with existing fragmentation, and by reordering and optimizing the on-disk structures. With optimizations in place, the performance on FAT volumes can often reach that of more sophisticated file systems in practical scenarios, while at the same time retaining the advantage of being accessible even on very small or old systems.

DOS 3.0 and higher will not immediately reuse disk space of deleted files for new allocations but instead seek for previously unused space before starting to use disk space of previously deleted files as well. This not only helps to maintain the integrity of deleted files for as long as possible but also speeds up file allocations and avoids fragmentation, since never before allocated disk space is always unfragmented. DOS accomplishes this by keeping a pointer to the last allocated cluster on each mounted volume in memory and starts searching for free space from this location upwards instead of at the beginning of the FAT, as it was still done by DOS 2.x.^[20] If the end of the FAT is reached, it would wrap around to continue the search at the beginning of the FAT until either free space has been found or the original position has been reached again without having found free space.^[20] These pointers are initialized to point to the start of the FATs after bootup,^[20] but on FAT32 volumes, DOS 7.1 and higher will attempt to retrieve the last position from the FS Information Sector. This mechanism is defeated, however, if an application often deletes and recreates temporary files as the operating system would then try to maintain the integrity of void data effectively causing more fragmentation in the end.^[20] In some DOS versions, the usage of a special API function to create temporary files can be used to avoid this problem.

Additionally, directory entries of deleted files will be marked 0xE5 since DOS 3.0.^[11] DOS 5.0 and higher will start to reuse these entries only when previously unused directory entries have been used up in the table and the system would otherwise have to expand the table itself.^[13]

Since DOS 3.3 the operating system provides means to improve the performance of file operations with FASTOPEN by keeping track of the position of recently opened files or directories in various forms of lists (MS-DOS/PC DOS) or hash tables (DR-DOS), which can reduce file seek and open times significantly. Before DOS 5.0 special care must be taken when using such mechanisms in conjunction with disk defragmentation software bypassing the file system or disk drivers.

Windows NT will allocate disk space to files on FAT in advance, selecting large contiguous areas, but in case of a failure, files which were being appended will appear larger than they were ever written into, with a lot of random data at the end.

Other high-level mechanisms may read in and process larger parts or the complete FAT on startup or on demand when needed and dynamically build up in-memory tree representations of the volume's file structures different from the on-disk structures.^[51][52] This may, on volumes with many free clusters, occupy even less memory than an image of the FAT itself. In particular on highly fragmented or filled volumes, seeks become much faster than with linear scans over the actual FAT, even if an image of the FAT would be stored in memory. Also, operating on the logically high level of files and cluster-chains instead of on sector or track level, it becomes possible to avoid some degree of file fragmentation in the first place or to carry out local file defragmentation and reordering of directory entries based on their names or access patterns in the background.

Some of the perceived problems with fragmentation of FAT file systems also result from performance limitations of the underlying block device drivers, which becomes more visible the lesser memory is available for sector buffering and track blocking/deblocking:

While the single-tasking DOS had provisions for multi-sector reads and track blocking/deblocking, the operating system and the traditional PC hard disk architecture (only one outstanding input/output request at a time and no DMA transfers) originally did not contain mechanisms which could alleviate fragmentation by asynchronously prefetching next data while the application was processing the previous chunks. Such features became available later. Later DOS versions also provided built-in support for look-ahead sector buffering and came with dynamically loadable disk caching programs working on physical or logical sector level, often utilizing EMS or XMS memory and sometimes providing adaptive caching strategies or even run in protected mode through DPMS or Cloaking to increase performance by gaining direct access to the cached data in linear memory rather than through conventional DOS APIs.

Write-behind caching was often not enabled by default with Microsoft software (if present) given the problem of data loss in case of a power failure or crash, made easier by the lack of hardware protection between applications and the system.

Directory table[edit]

A directory table is a special type of file that represents a directory (also known as a folder). Since 86-DOS 0.42,^[53] each file or (since MS-DOS 1.40 and PC DOS 2.0) subdirectory stored within it is represented by a 32-byte entry in the table. Each entry records the name, extension, attributes (archive, directory, hidden, read-only, system and volume), the address of the first cluster of the file/directory's data, the size of the file/directory, and the date^[53] and (since PC DOS 1.1) also the time of last modification. Earlier versions of 86-DOS used 16-byte directory entries only, supporting no files larger than 16 MB and no time of last modification.^[53]

Aside from the root directory table in FAT12 and FAT16 file systems, which occupies the special Root Directory Region location, all directory tables are stored in the data region. The actual number of entries in a directory stored in the data region can grow by adding another cluster to the chain in the FAT.

The FAT file system itself does not impose any limits on the depth of a subdirectory tree for as long as there are free clusters available to allocate the subdirectories, however, the internal Current Directory Structure (CDS) under MS-DOS/PC DOS limits the absolute path of a directory to 66 characters (including the drive letter, but excluding the NUL byte delimiter),^[5][6][7] thereby limiting the maximum supported depth of subdirectories to 32, whatever occurs earlier. Concurrent DOS, Multiuser DOS and DR DOS 3.31 to 6.0 (up to including the 1992-11 updates) do not store absolute paths to working directories internally and therefore do not show this limitation.^[54] The same applies to Atari GEMDOS, but the Atari Desktop does not support more than 8 sub-directory levels. Most applications aware of this extension support paths up to at least 127 bytes. FlexOS, 4680 OS and 4690 OS support a length of up to 127 bytes as well, allowing depths down to 60 levels.^[55] PalmDOS, DR DOS 6.0 (since BDOS 7.1) and higher, Novell DOS, and OpenDOS sport a MS-DOS-compatible CDS and therefore have the same length limits as MS-DOS/PC DOS.

Each entry can be preceded by "fake entries" to support a VFAT long filename (LFN); see further below.

Legal characters for DOS short filenames include the following:

• Upper case letters A–Z
• Numbers 0–9
• Space (though trailing spaces in either the base name or the extension are considered to be padding and not a part of the file name; also filenames with space in them could not easily be used on the DOS command line prior to Windows 95 because of the lack of a suitable escaping system). Another exception are the internal commands MKDIR/MD and RMDIR/RD under DR-DOS which accept single arguments and therefore allow spaces to be entered.
• ! # $ % & ' ( ) - @ ^ _ ` { } ~
• Characters 128–228
• Characters 230–255

This excludes the following ASCII characters:

• " * / : < > ? \ |
  Windows/MS-DOS has no shell escape character
• + , . ; = [ ]
  Allowed in long file names only
• Lower case letters a–z
  Stored as A–Z; allowed in long file names
• Control characters 0–31
• Character 127 (DEL)

Character 229 (0xE5) was not allowed as first character in a filename in DOS 1 and 2 due to its use as free entry marker. A special case was added to circumvent this limitation with DOS 3.0 and higher.

The following additional characters are allowed on Atari's GEMDOS, but should be avoided for compatibility with MS-DOS/PC DOS:

• " + , ; < = > [ ] |

The semicolon (;) should be avoided in filenames under DR DOS 3.31 and higher, PalmDOS, Novell DOS, OpenDOS, Concurrent DOS, Multiuser DOS, System Manager and REAL/32, because it may conflict with the syntax to specify file and directory passwords: "...\DIRSPEC.EXT;DIRPWD\FILESPEC.EXT;FILEPWD". The operating system will strip off one^[54] (and also two—since DR-DOS 7.02) semicolons and pending passwords from the filenames before storing them on disk. (The command processor 4DOS uses semicolons for include lists and requires the semicolon to be doubled for password protected files with any commands supporting wildcards.^[54])

The at-sign character (@) is used for filelists by many DR-DOS, PalmDOS, Novell DOS, OpenDOS and Multiuser DOS, System Manager and REAL/32 commands, as well as by 4DOS and may therefore sometimes be difficult to use in filenames.^[54]

Under Multiuser DOS and REAL/32, the exclamation mark (!) is not a valid filename character since it is used to separate multiple commands in a single command line.^[54]

Under IBM 4680 OS and 4690 OS, the following characters are not allowed in filenames:

• ? * : . ; , [ ] ! + = < > " - / \ |

Additionally, the following special characters are not allowed in the first, fourth, fifth and eight character of a filename, as they conflict with the host command processor (HCP) and input sequence table build file names:

• @ # ( ) { } $ &

The DOS file names are in the current OEM character set: this can have surprising effects if characters handled in one way for a given code page are interpreted differently for another code page (DOS command CHCP) with respect to lower and upper case, sorting, or validity as file name character.

Directory entry[edit]

Before Microsoft added support for long filenames and creation/access time stamps, bytes 0x0C–0x15 of the directory entry were used by other operating systems to store additional metadata, most notably the operating systems of the Digital Research family stored file passwords, access rights, owner IDs, and file deletion data there. While Microsoft's newer extensions are not fully compatible with these extensions by default, most of them can coexist in third-party FAT implementations (at least on FAT12 and FAT16 volumes).

32-byte directory entries, both in the Root Directory Region and in subdirectories, are of the following format (see also 8.3 filename):

The FlexOS-based operating systems IBM 4680 OS and IBM 4690 OS support unique distribution attributes stored in some bits of the previously reserved areas in the directory entries:^[68]

1. Local: Don't distribute file but keep on local controller only.^{[nb 14]}
2. Mirror file on update: Distribute file to server only when file is updated.
3. Mirror file on close: Distribute file to server only when file is closed.
4. Compound file on update: Distribute file to all controllers when file is updated.
5. Compound file on close: Distribute file to all controllers when file is closed.^[69]

Some incompatible extensions found in some operating systems include:

VFAT long file names[edit]

VFAT Long File Names (LFNs) are stored on a FAT file system using a trick: adding additional entries into the directory before the normal file entry. The additional entries are marked with the Volume Label, System, Hidden, and Read Only attributes (yielding 0x0F), which is a combination that is not expected in the MS-DOS environment, and therefore ignored by MS-DOS programs and third-party utilities. Notably, a directory containing only volume labels is considered as empty and is allowed to be deleted; such a situation appears if files created with long names are deleted from plain DOS. This method is very similar to the DELWATCH method to utilize the volume attribute to hide pending delete files for possible future undeletion since DR DOS 6.0 (1991) and higher. It is also similar to a method publicly discussed to store long filenames on Ataris and under Linux in 1992.^[70][71]

Because older versions of DOS could mistake LFN names in the root directory for the volume label, VFAT was designed to create a blank volume label in the root directory before adding any LFN name entries (if a volume label did not already exist).^{[nb 13]}

Each phony entry can contain up to 13 UCS-2 characters (26 bytes) by using fields in the record which contain file size or time stamps (but not the starting cluster field, for compatibility with disk utilities, the starting cluster field is set to a value of 0. See 8.3 filename for additional explanations). Up to 20 of these 13-character entries may be chained, supporting a maximum length of 255 UCS-2 characters.^[61]

After the last UCS-2 character, a 0x0000 is added. The remaining unused characters are filled with 0xFFFF.

LFN entries use the following format:

If there are multiple LFN entries required to represent a file name, the entry representing the end of the filename comes first. The sequence number of this entry has bit 6 (0x40) set to represent that it is the last logical LFN entry, and it has the highest sequence number. The sequence number decreases in the following entries. The entry representing the start of the filename has sequence number 1. A value of 0xE5 is used to indicate that the entry is deleted.

On FAT12 and FAT16 volumes, testing for the values at 0x1A to be zero and at 0x1C to be non-zero can be used to distinguish between VFAT LFNs and pending delete files under DELWATCH.

For example, a filename like "File with very long filename.ext" would be formatted like this:

A checksum also allows verification of whether a long file name matches the 8.3 name; such a mismatch could occur if a file was deleted and re-created using DOS in the same directory position. The checksum is calculated using the algorithm below. (pFCBName is a pointer to the name as it appears in a regular directory entry, i.e. the first eight characters are the filename, and the last three are the extension. The dot is implicit. Any unused space in the filename is padded with space characters (ASCII 0x20). For example, "Readme.txt" would be "README␠␠TXT".)

unsigned char lfn_checksum(const unsigned char *pFCBName){ int i; unsigned char sum = 0; for (i = 11; i; i--) sum = ((sum & 1) << 7) + (sum >> 1) + *pFCBName++; return sum;}

If a filename contains only lowercase letters, or is a combination of a lowercase basename with an uppercase extension, or vice versa; and has no special characters, and fits within the 8.3 limits, a VFAT entry is not created on Windows NT and later versions of Windows such as XP. Instead, two bits in byte 0x0C of the directory entry are used to indicate that the filename should be considered as entirely or partially lowercase. Specifically, bit 4 means lowercase extension and bit 3 lowercase basename, which allows for combinations such as "example.TXT" or "HELLO.txt" but not "Mixed.txt". Few other operating systems support it. This creates a backwards-compatibility problem with older Windows versions (Windows 95 / 98 / 98 SE / ME) that see all-uppercase filenames if this extension has been used, and therefore can change the name of a file when it is transported between operating systems, such as on a USB flash drive. Current 2.6.x versions of Linux will recognize this extension when reading (source: kernel 2.6.18 /fs/fat/dir.c and fs/vfat/namei.c); the mount option shortname determines whether this feature is used when writing.^[72]

See also[edit]

• Comparison of file systems
• Drive letter assignment
• exFAT
• Extended Boot Record (EBR)
• FAT filesystem and Linux
• List of file systems
• Master Boot Record (MBR)
• Partition type
• Timeline of DOS operating systems
• Transaction-Safe FAT File System
• Turbo FAT
• Volume Boot Record (VBR)

Notes[edit]

References[edit]

External links[edit]

• ECMA-107 Volume and File Structure of Disk Cartridges for Information Interchange, identical to ISO/IEC 9293.
• Microsoft Extensible Firmware Initiative FAT32 File System Specification, FAT: General Overview of On-Disk Format
• Understanding FAT32 file systems (explained for embedded firmware developers)
• Understanding FAT including lots of info about LFNs
• Detailed Explanation of FAT Boot Sector: Microsoft Knowledge Base Article 140418
• Description of the FAT32 File System: Microsoft Knowledge Base Article 154997
• FAT12/FAT16/FAT32 file system implementation for *nix: Includes libfat libraries and fusefat, a FUSE file system driver
• MS-DOS: Directory and Subdirectory Limitations: Microsoft Knowledge Base Article 39927
• Overview of FAT, HPFS, and NTFS File Systems: Microsoft Knowledge Base Article 100108
• Volume and file size limits of FAT file systems: Microsoft Technet, copy made by Internet Archive Wayback Machine
• Microsoft TechNet: A Brief and Incomplete History of FAT32 by Raymond Chen
• FAT32 Formatter: allows formatting volumes larger than 32 GB with FAT32 under Windows 2000, Windows XP and Windows Vista
• Fdisk does not recognize full size of hard disks larger than 64 GB: Microsoft Knowledge Base Article 263044.
• Microsoft Windows XP: FAT32 File System. Copy made by Internet Archive Wayback Machine of an article with summary of limits in FAT32 which is no longer available on Microsoft website.
• Visual Layout of a FAT16 drive