Проектирование файловой системы FAT

This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages) This article may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (September 2021) (Learn how and when to remove this message) This article duplicates the scope of other articles, specifically FAT file system. Please discuss this issue and help introduce a summary style to the article. (January 2023) (Learn how and when to remove this message)

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

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

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

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

DOS 3.0 БПБ:

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

DOS 3.2 БПБ:

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

ДОС 3.31 БПБ:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 начинается с байта идентификатора носителя/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. ^[37]

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

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

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

This article may overuse or misuse colour, making it hard to understand for colour-blind users. Please remove or fix instances of distracting or hard-to-read colours or remove coloured links that may impede users' ability to distinguish links from regular text, or links coloured for purely aesthetic reasons. See the guides to editing for accessibility of contrast and colour.

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

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

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

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

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

Файловая система FAT32 использует 32 бита на запись FAT, таким образом, одна запись охватывает четыре байта в порядке little-endian. Четыре верхних бита каждой записи зарезервированы для других целей; они очищаются во время форматирования и не должны изменяться в противном случае. Они должны быть замаскированы перед интерпретацией записи как 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, 4 бита MSB равны нулю) этой записи всегда равны 1. Эти значения были организованы таким образом, чтобы запись также функционировала как маркер конца цепочки "trap-all" для всех кластеров данных, содержащих нулевое значение. Кроме того, для идентификаторов FAT, отличных от 0xFF (и 0x00 ), можно определить правильный порядок полубайтов и байтов, который будет использоваться драйвером файловой системы, однако официально файловая система FAT использует только представление с прямым порядком байтов , и нет известных реализаций вариантов, использующих значения с обратным порядком байтов . 86-DOS 0.42 вплоть до MS-DOS 1.14 использовали жестко заданные профили дисков вместо идентификатора FAT, но использовали этот байт для различения носителей, отформатированных с 32-байтовыми или 16-байтовыми записями каталогов, как это было до 86-DOS 0.42.

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

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

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

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

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

Значения ввода FAT:

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

Таблица корневого каталога в файловых системах FAT12 и FAT16 занимает специальное местоположение области корневого каталога .

За исключением таблицы корневого каталога в файловых системах FAT12 и FAT16, которая занимает специальное местоположение Root Directory Region , все таблицы каталогов хранятся в регионе данных. Фактическое количество записей в каталоге, хранящемся в регионе данных, может увеличиваться путем добавления еще одного кластера в цепочку в FAT.

Таблица каталогов — это особый тип файла, представляющий каталог (также известный как папка). Начиная с 86-DOS 0.42 [ ^46] каждый файл или (начиная с MS-DOS 1.40 и PC DOS 2.0) подкаталог, хранящийся в нем, представлен 32-байтовой записью в таблице. Каждая запись записывает имя, расширение, атрибуты ( архив , каталог, скрытый, только для чтения, системный и том), адрес первого кластера данных файла/каталога, размер файла/каталога и дату ^[46] и (начиная с PC DOS 1.1) также время последнего изменения. Более ранние версии 86-DOS использовали только 16-байтовые записи каталогов, не поддерживая файлы размером более 16 МБ и не поддерживая время последнего изменения. ^[46]

Сама файловая система FAT не накладывает никаких ограничений на глубину дерева подкаталогов, пока есть свободные кластеры, доступные для размещения подкаталогов, однако внутренняя структура текущего каталога (CDS) в MS-DOS/PC DOS ограничивает абсолютный путь к каталогу 66 символами (включая букву диска, но исключая разделитель байтов NUL), ^{[24] [25] [26]} тем самым ограничивая максимальную поддерживаемую глубину подкаталогов 32, что бы ни произошло раньше. Concurrent DOS, Multiuser DOS и DR DOS 3.31 по 6.0 (до включения обновлений 1992-11) не хранят абсолютные пути к рабочим каталогам внутри себя и, следовательно, не показывают это ограничение. ^[47] То же самое относится к Atari GEMDOS, но Atari Desktop не поддерживает более 8 уровней подкаталогов. Большинство приложений, знающих об этом расширении, поддерживают пути длиной не менее 127 байт. FlexOS, 4680 OS и 4690 OS также поддерживают длину до 127 байт, что позволяет использовать глубину до 60 уровней. ^[48] PalmDOS, DR DOS 6.0 (начиная с BDOS 7.1) и выше, Novell DOS и OpenDOS поддерживают совместимый с MS-DOS CDS и, следовательно, имеют те же ограничения по длине, что и MS-DOS/PC DOS.

Каждой записи могут предшествовать «поддельные записи» для поддержки длинного имени файла VFAT (LFN); см. подробнее ниже.

Допустимые символы для коротких имен файлов DOS включают следующие:

• Заглавные буквы A–Z
• Числа 0–9
• Пробел (хотя конечные пробелы в базовом имени или расширении считаются заполнением, а не частью имени файла; кроме того, имена файлов с пробелами в них не могли легко использоваться в командной строке DOS до Windows 95 из-за отсутствия подходящей системы экранирования ). Другим исключением являются внутренние команды MKDIR/ MDи RMDIR/ RDв DR-DOS, которые принимают одиночные аргументы и, следовательно, позволяют вводить пробелы.
• ! # $ % & ' ( ) - @ ^ _ ` { } ~
• Персонажи 128–228
• Персонажи 230–255

Это исключает следующие символы ASCII :

• " * / : < > ? \ |
  В Windows/MS-DOS нет символа escape- оболочки
• + , . ; = [ ]
  Разрешено только в длинных именах файлов.
• Строчные буквы a– z
  Сохраняются как A– Z; разрешены в длинных именах файлов
• Управляющие символы 0–31
• Символ 127 (DEL)

Символ 229 ( 0xE5 ) не допускался в качестве первого символа в имени файла в DOS 1 и 2 из-за его использования в качестве свободного маркера записи. Был добавлен специальный случай, чтобы обойти это ограничение в DOS 3.0 и выше.

В GEMDOS от Atari разрешены следующие дополнительные символы, но их следует избегать для совместимости с MS-DOS/PC DOS:

• " + , ; < = > [ ] |

Точку с запятой ( ;) следует избегать в именах файлов в DR DOS 3.31 и выше, PalmDOS, Novell DOS, OpenDOS, Concurrent DOS, Multiuser DOS, System Manager и REAL/32, поскольку она может конфликтовать с синтаксисом указания паролей файлов и каталогов: " ...\DIRSPEC.EXT;DIRPWD\FILESPEC.EXT;FILEPWD". Операционная система удалит одну ^[47] (а также две — начиная с DR-DOS 7.02) точки с запятой и ожидающие пароли из имен файлов перед сохранением их на диске. (Командный процессор 4DOS использует точки с запятой для списков включения и требует удвоения точки с запятой для защищенных паролем файлов с любыми командами, поддерживающими подстановочные знаки. ^[47] )

Символ «at» ( @) используется для списков файлов многими командами DR-DOS, PalmDOS, Novell DOS, OpenDOS и Multiuser DOS, System Manager и REAL/32, а также 4DOS, и поэтому иногда его может быть сложно использовать в именах файлов. ^[47]

В многопользовательских DOS и REAL/32 восклицательный знак (!) не является допустимым символом имени файла, поскольку он используется для разделения нескольких команд в одной командной строке. ^[47]

В ОС IBM 4680 и 4690 в именах файлов не допускаются следующие символы:

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

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

• @ # ( ) { } $ &

Имена файлов DOS находятся в текущем наборе символов OEM : это может иметь неожиданные последствия, если символы, обрабатываемые одним способом для данной кодовой страницы, интерпретируются по-разному для другой кодовой страницы (команда DOS CHCP) с точки зрения нижнего и верхнего регистра, сортировки или допустимости в качестве символа имени файла.

До того, как Microsoft добавила поддержку длинных имен файлов и временных меток создания/доступа, байты 0x0C – 0x15 записи каталога использовались другими операционными системами для хранения дополнительных метаданных, в частности, операционные системы семейства Digital Research хранили там пароли файлов, права доступа, идентификаторы владельцев и данные об удалении файлов. Хотя новые расширения Microsoft по умолчанию не полностью совместимы с этими расширениями, большинство из них могут сосуществовать в сторонних реализациях FAT (по крайней мере, на томах FAT12 и FAT16).

32-байтовые записи каталогов, как в области корневого каталога, так и в подкаталогах, имеют следующий формат (см. также 8.3 имя_файла ):

Операционные системы IBM 4680 OS и IBM 4690 OS на базе FlexOS поддерживают уникальные атрибуты распределения, хранящиеся в некоторых битах ранее зарезервированных областей в записях каталога: ^[62]

1. Локально: Не распространять файл, а хранить только на локальном контроллере. ^{[nb 14]}
2. Зеркальное отображение файла при обновлении: передача файла на сервер только после его обновления.
3. Зеркальное копирование файла при закрытии: передача файла на сервер только после его закрытия.
4. Составной файл при обновлении: Распространить файл на все контроллеры после обновления файла.
5. Составной файл при закрытии: Распространить файл на все контроллеры при закрытии файла. ^[63]

Некоторые несовместимые расширения, обнаруженные в некоторых операционных системах, включают:

Варианты файловых систем FAT12, FAT16, FAT16B и FAT32 имеют четкие ограничения, основанные на количестве кластеров и количестве секторов на кластер (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 до 65524 кластеров: от 16 до 256 секторов на копию FAT
Диапазон FAT32: от 65525 до 268435444 кластеров: от 512 до 2097152 секторов на копию FAT

Минимум FAT12: 1 сектор на кластер × 1 кластер = 512 байт (0,5 КиБ)
Минимум FAT16: 1 сектор на кластер × 4085 кластеров = 2091520 байт (2042,5 КБ)
Минимум FAT32: 1 сектор на кластер × 65525 кластеров = 33548800 байт (32762,5 КБ)

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

Максимум FAT16: 64 сектора на кластер × 65524 кластера = 2147090432 байт (≈2047 МБ)
[FAT16 максимум: 128 секторов на кластер × 65 524 кластера = 4 294 180 864 байта (≈4 095 МБ)]

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

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

Поскольку каждая запись 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 NTFORMAT параметры команды /A:128Kи /A:256Kсоответствуют максимальному размеру кластера 0x80(128) с размером сектора 1024 и 2048 соответственно. Для общего размера сектора 512 /A:64Kполучается 128 секторов на кластер.

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

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

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

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

...когда написано <, это не значит <=. Обратите внимание, что числа верны. Первое число для FAT12 — 4085; второе число для FAT16 — 65525. Эти числа и знаки «<» не являются неправильными.

Файловая система FAT не содержит встроенных механизмов, которые предотвращают разбросанность вновь записанных файлов по разделу. ^[65] На томах, где файлы часто создаются и удаляются или их длина часто меняется, носитель со временем будет становиться все более фрагментированным.

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

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

Фактически, поиск файлов в больших подкаталогах или вычисление свободного дискового пространства на томах FAT является одной из самых ресурсоемких операций, поскольку требует чтения таблиц каталогов или даже всего FAT линейно. Поскольку общее количество кластеров и размер их записей в FAT все еще были небольшими на томах FAT12 и FAT16, это все еще можно было бы допустить на томах FAT12 и FAT16 большую часть времени, учитывая, что введение более сложных структур дисков также увеличило бы сложность и объем памяти операционных систем реального режима с их минимальными требованиями к общей памяти 128 КБ или меньше (например, с DOS), для которых FAT был изначально разработан и оптимизирован.

С введением FAT32 длительное время поиска и сканирования стало более очевидным, особенно на очень больших томах. Возможным оправданием, предложенным Рэймондом Ченом из Microsoft для ограничения максимального размера разделов FAT32, созданных в Windows, было время, необходимое для выполнения операции " DIR", которая всегда отображает свободное дисковое пространство в качестве последней строки. ^[66] Отображение этой строки занимало все больше времени по мере увеличения числа кластеров. Поэтому FAT32 ввел специальный сектор информации о файловой системе, где ранее вычисленный объем свободного пространства сохраняется при циклах питания, так что счетчик свободного пространства необходимо пересчитывать только тогда, когда съемный носитель, отформатированный FAT32, извлекается без предварительного его размонтирования или если система выключается без надлежащего завершения работы операционной системы, проблема, в основном заметная на ПК до ATX -стиля, на простых системах DOS и некоторых потребительских продуктах с батарейным питанием.

Из-за огромных размеров кластеров (16 КБ, 32 КБ, 64 КБ), обусловленных большими разделами FAT, внутренняя фрагментация в виде потери дискового пространства из-за нехватки файлов из-за переполнения кластера (поскольку файлы редко бывают точно кратны размеру кластера) также начинает представлять собой проблему, особенно когда имеется очень много мелких файлов.

Различные оптимизации и настройки для реализации драйверов файловой системы FAT, драйверов блочных устройств и дисковых инструментов были разработаны для преодоления большинства узких мест производительности в изначальной конструкции файловой системы без необходимости изменения компоновки структур на диске. ^{[67] [68]} Их можно разделить на онлайновые и офлайновые методы, и они работают, пытаясь в первую очередь избежать фрагментации в файловой системе, развертывая методы для лучшего совладания с существующей фрагментацией и переупорядочивая и оптимизируя структуры на диске. При наличии оптимизаций производительность томов FAT часто может достигать производительности более сложных файловых систем в практических сценариях, в то же время сохраняя преимущество доступности даже на очень маленьких или старых системах.

DOS 3.0 и выше не будут немедленно повторно использовать дисковое пространство удаленных файлов для новых выделений, а вместо этого будут искать ранее неиспользованное пространство, прежде чем начать использовать дисковое пространство ранее удаленных файлов. Это не только помогает поддерживать целостность удаленных файлов как можно дольше, но также ускоряет выделение файлов и избегает фрагментации, поскольку никогда ранее не выделявшееся дисковое пространство всегда нефрагментировано. DOS достигает этого, сохраняя указатель на последний выделенный кластер на каждом смонтированном томе в памяти и начинает поиск свободного пространства с этого места вверх, а не с начала FAT, как это все еще делалось в DOS 2.x. ^[13] Если достигнут конец FAT, он будет перезапускаться, чтобы продолжить поиск с начала FAT, пока либо не будет найдено свободное место, либо не будет достигнута исходная позиция снова без нахождения свободного места. ^[13] Эти указатели инициализируются для указания на начало FAT после загрузки, ^[13] но на томах FAT32 DOS 7.1 и выше попытаются извлечь последнюю позицию из сектора информации FS. Однако этот механизм не работает, если приложение часто удаляет и заново создает временные файлы, поскольку операционная система затем попытается сохранить целостность пустых данных, что в конечном итоге приведет к большей фрагментации. ^[13] В некоторых версиях DOS для избежания этой проблемы можно использовать специальную функцию API для создания временных файлов.

Кроме того, записи каталога удаленных файлов будут помечены как 0xE5 , начиная с DOS 3.0. ^[42] DOS 5.0 и выше начнут повторно использовать эти записи только тогда, когда ранее неиспользованные записи каталога будут израсходованы в таблице, и в противном случае системе пришлось бы расширять таблицу самостоятельно. ^[6]

Начиная с DOS 3.3 операционная система предоставляет средства для повышения производительности файловых операций FASTOPENпутем отслеживания положения недавно открытых файлов или каталогов в различных формах списков (MS-DOS/PC DOS) или хэш-таблиц (DR-DOS), что может значительно сократить время поиска и открытия файлов. До DOS 5.0 необходимо соблюдать особую осторожность при использовании таких механизмов в сочетании с программным обеспечением для дефрагментации диска, обходящим файловую систему или драйверы диска.

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

Другие высокоуровневые механизмы могут считывать и обрабатывать более крупные части или всю FAT при запуске или по требованию, когда это необходимо, и динамически создавать в памяти древовидные представления файловых структур тома, отличающиеся от структур на диске. ^{[67] [68]} Это может, на томах со многими свободными кластерами, занимать даже меньше памяти, чем образ самой FAT. В частности, на сильно фрагментированных или заполненных томах поиск становится намного быстрее, чем при линейном сканировании по фактической FAT, даже если образ FAT будет храниться в памяти. Кроме того, работая на логически высоком уровне файлов и цепочек кластеров вместо уровня сектора или дорожки, становится возможным избежать некоторой степени фрагментации файла в первую очередь или выполнить локальную дефрагментацию файлов и переупорядочение записей каталога на основе их имен или шаблонов доступа в фоновом режиме.

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

В то время как однозадачная DOS имела возможности для многосекторного чтения и блокировки/деблокировки дорожек, операционная система и традиционная архитектура жесткого диска ПК ( только один невыполненный запрос ввода/вывода за раз и никаких передач DMA ) изначально не содержали механизмов, которые могли бы уменьшить фрагментацию путем асинхронной предварительной выборки следующих данных, пока приложение обрабатывало предыдущие фрагменты. Такие функции стали доступны позже. Более поздние версии DOS также обеспечивали встроенную поддержку буферизации секторов с упреждением и поставлялись с динамически загружаемыми программами кэширования диска, работающими на физическом или логическом уровне секторов, часто используя память EMS или XMS и иногда предоставляя адаптивные стратегии кэширования или даже работая в защищенном режиме через DPMS или Cloaking для повышения производительности за счет получения прямого доступа к кэшированным данным в линейной памяти, а не через обычные API DOS.

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

Длинные имена файлов VFAT (LFN) хранятся в файловой системе FAT с помощью трюка: добавления дополнительных записей в каталог перед обычной записью файла. Дополнительные записи помечаются атрибутами Volume Label, System, Hidden и Read Only (что приводит к 0x0F ), что является комбинацией, которая не ожидается в среде MS-DOS, и поэтому игнорируется программами MS-DOS и сторонними утилитами. В частности, каталог, содержащий только метки томов, считается пустым и может быть удален; такая ситуация возникает, если файлы, созданные с длинными именами, удаляются из обычного DOS. Этот метод очень похож на метод DELWATCH для использования атрибута тома для скрытия ожидающих удаления файлов для возможного восстановления в будущем, начиная с DR DOS 6.0 (1991) и выше. Он также похож на метод, публично обсуждавшийся для хранения длинных имен файлов в Ataris и под Linux в 1992 году. ^{[69] [70]}

Поскольку старые версии DOS могли ошибочно принимать имена LFN в корневом каталоге за метку тома, VFAT был разработан для создания пустой метки тома в корневом каталоге перед добавлением любых записей имен LFN (если метка тома еще не существовала). ^{[примечание 13]}

Каждая фальшивая запись может содержать до 13 символов UCS-2 (26 байт) с использованием полей в записи, содержащих размер файла или временные метки (но не поле начального кластера, для совместимости с дисковыми утилитами поле начального кластера установлено на значение 0. См. 8.3 имя файла для дополнительных объяснений). До 20 из этих 13-символьных записей могут быть объединены в цепочку, поддерживая максимальную длину 255 символов UCS-2. ^[55]

Если позиция последнего символа LFN не находится на границе записи каталога (13, 26, 39, ...), то в следующую позицию символа добавляется терминатор 0x0000 . Затем, если этот терминатор также не находится на границе, оставшиеся позиции символов заполняются 0xFFFF . Не будет существовать ни одной записи каталога, содержащей одинокий терминатор.

Записи LFN используют следующий формат:

Если для представления имени файла требуется несколько записей LFN, запись, представляющая конец имени файла, идет первой. Порядковый номер этой записи имеет бит 6 ( 0x40 ), установленный для представления того, что это последняя логическая запись LFN, и она имеет наивысший порядковый номер. Порядковый номер уменьшается в следующих записях. Запись, представляющая начало имени файла, имеет порядковый номер 1. Значение 0xE5 используется для указания того, что запись удалена.

На томах FAT12 и FAT16 проверка значений 0x1A на равенство нулю и значений 0x1C на ненулевое значение может использоваться для различения VFAT LFN и ожидающих удаления файлов в DELWATCH.

Например, имя файла «Файл с очень длинным именем.ext» будет отформатировано следующим образом:

Контрольная сумма также позволяет проверить, соответствует ли длинное имя файла имени 8.3; такое несоответствие может возникнуть, если файл был удален и создан заново с помощью DOS в той же позиции каталога. Контрольная сумма вычисляется с использованием алгоритма ниже. (pFCBName — это указатель на имя, как оно отображается в обычной записи каталога, т. е. первые восемь символов — это имя файла, а последние три — расширение. Точка подразумевается. Любое неиспользуемое пространство в имени файла заполняется пробелами (ASCII 0x20 ). Например, "Readme.txt" будет иметь вид " ".)README␠␠TXT

беззнаковый символ lfn_checksum ( const беззнаковый символ * pFCBName ) { int i ; беззнаковый символ sum = 0 ;             для ( i = 11 ; i ; i -- ) сумма = (( сумма & 1 ) << 7 ) + ( сумма >> 1 ) + * pFCBName ++ ;                   вернуть сумму ; } 

Если имя файла содержит только строчные буквы или представляет собой комбинацию нижнего регистра базового имени с заглавным расширением или наоборот; и не имеет специальных символов и соответствует ограничениям 8.3, запись VFAT не создается в Windows NT и более поздних версиях Windows, таких как XP. Вместо этого два бита в байте 0x0C записи каталога используются для указания того, что имя файла следует считать полностью или частично строчным. В частности, бит 4 означает нижнее расширение , а бит 3 — нижнее регистровое базовое имя , что допускает такие комбинации, как " " или " ", но не " ". Немногие другие операционные системы поддерживают это. Это создает проблему обратной совместимости со старыми версиями Windows (Windows 95 / 98 / 98 SE / ME), которые видят имена файлов, состоящие полностью из заглавных букв, если использовалось это расширение, и, следовательно, могут изменить имя файла при его переносе между операционными системами, например, на флэш-накопителе USB. Текущие версии Linux 2.6.x распознают это расширение при чтении (источник: ядро ​​2.6.18 и ); параметр монтирования определяет, будет ли эта функция использоваться при записи. ^[71]example.TXTHELLO.txtMixed.txt/fs/fat/dir.cfs/vfat/namei.cshortname

• Сравнение файловых систем
• Назначение букв дискам
• эксFAT
• Расширенная загрузочная запись (EBR)
• Файловая система FAT и Linux
• Список файловых систем
• Основная загрузочная запись (MBR)
• Тип раздела
• Хронология операционных систем DOS
• Файловая система FAT с безопасными транзакциями
• Турбо ЖИР
• Загрузочная запись тома (VBR)

• ECMA-107 Структура томов и файлов дисковых картриджей для обмена информацией, идентично ISO/IEC 9293.
• Спецификация файловой системы FAT32 от Microsoft Extensible Firmware Initiative, FAT: общий обзор формата на диске
• Понимание файловых систем FAT32 (объяснение для разработчиков встроенного ПО)
• Понимание FAT, включая много информации о LFN
• Подробное объяснение загрузочного сектора FAT: статья базы знаний Microsoft 140418
• Описание файловой системы FAT32: статья базы знаний Microsoft 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 Archived 2009-07-21 at the Wayback Machine: 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, copy made by Internet Archive Wayback Machine. Explains inability to work with extremely large volumes under Windows 95/98.
• 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