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

Для более широкого освещения этой темы см. Таблицу размещения файлов .

ТОЛСТЫЙ

Разработчик(и)	Microsoft , SCP , IBM , Compaq , Digital Research , Novell , Caldera
Полное имя	Таблица размещения файлов: FAT12 (12-битная версия), FAT16 (16-битные версии), FAT32 (32-битная версия с использованием 28 бит), exFAT (64-битные версии)
Представлено	1977 ( Автономный диск BASIC-80 ) FAT12: август 1980 г. (SCP QDOS ) FAT16: август 1984 г. (IBM PC DOS 3.0) FAT16B: ноябрь 1987 г. ( Compaq MS-DOS 3.31) FAT32: август 1996 г. ( Windows 95 OSR2 ) exFAT: ноябрь 2006 г. ( Windows Embedded CE 6.0 )
Идентификаторы разделов	МБР / ЭБР : ФАТ12 : 0x01 еа ФАТ16 : 0x040x060x0E еа ФАТ32 : 0x0B0x0C еа exFAT : 0x07 еа ВВП : EBD0A0A2-B9E5-4433­87C0-68B6B72699C7
Структуры
Содержимое каталога	Стол
Распределение файлов	Связанный список
Плохие блоки	Маркировка кластеров
Пределы
Максимальный размер тома	FAT12: 32 МБ (256 МБ 64 КБ ) для кластеров FAT16: 2 ГБ (4 ГБ для 64 КБ ) кластеров FAT32: 2 ТБ (16 ТБ для по 4 КБ секторов )
Максимальный размер файла	4 294 967 295 байт (4 ГБ — 1) с FAT16B и FAT32
Макс нет. файлов	FAT12: 4068 для 8 КБ. кластеров FAT16: 65 460 для 32 КБ. кластеров FAT32: 268 173 300 для 32 КБ. кластеров
Максимальная длина имени файла	Имя файла 8.3 или 255 символов UCS-2 при использовании LFN.
Функции
Даты записи	Дата/время изменения, дата/время создания (только для DOS 7.0 и выше), дата доступа (доступно только при включенном ACCDATE ), дата/время удаления (только с DELWATCH 2)
Диапазон дат	С 1 января 1980 г. по 31 декабря 2099 г. ( 31 декабря 2107 г. )
Разрешение даты	2 секунды для времени последнего изменения, 10 мс на время создания, 1 день на дату доступа, 2 секунды на время удаления
Вилки	Не изначально
Атрибуты	Только для чтения , Скрытый , Системный , Том , Каталог , Архив
Файловая система разрешения	FAT12/FAT16: права доступа к файлам, каталогам и томам для чтения , записи , выполнения , удаления только с DR-DOS , PalmDOS , Novell DOS , OpenDOS , FlexOS , 4680 OS , 4690 OS , Concurrent DOS , Multiuser DOS , System Manager , REAL /32 (право на выполнение только в FlexOS, 4680 OS, 4690 OS; пароли отдельных файлов/каталогов отсутствуют в FlexOS, 4680 OS, 4690 OS; классы разрешений World / Group / Owner только с загруженной многопользовательской защитой) FAT32: частичная, только для ОС DR-DOS, REAL/32 и 4690.
Прозрачный сжатие	FAT12/FAT16: для каждого тома, SuperStor , Stacker , DoubleSpace , DriveSpace. FAT32: Нет
Прозрачный шифрование	FAT12/FAT16: только для каждого тома с DR-DOS. FAT32: Нет

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

Структура

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

Регионы файловой системы FAT, включающие четыре основных региона.

Область	Размер в секторах	Содержание	Примечания
Зарезервированные сектора	(количество зарезервированных секторов )	Загрузочный сектор	Первый зарезервированный сектор (логический сектор 0) — это загрузочный сектор (также называемый загрузочной записью тома или просто VBR ). Он включает в себя область, называемую блоком параметров BIOS ( BPB ), которая содержит некоторую базовую информацию о файловой системе, в частности ее тип и указатели на расположение других разделов, и обычно содержит загрузчика код операционной системы. Важная информация из загрузочного сектора доступна через структуру операционной системы, называемую блоком параметров диска ( DPB ) в DOS и OS/2. Общее количество зарезервированных секторов указывается в поле внутри загрузочного сектора и обычно составляет 32 в файловых системах FAT32. Для файловых систем FAT32 зарезервированные сектора включают сектор информации о файловой системе в логическом секторе 1 и резервный загрузочный сектор в логическом секторе 6. В то время как многие другие поставщики продолжают использовать односекторную настройку (только логический сектор 0) для начальной загрузки. загрузчика, код загрузочного сектора Microsoft с момента появления FAT32 расширился и теперь охватывает логические сектора 0 и 2, причем логический сектор 0 зависит от подпрограмм в логическом секторе 2. Область резервного загрузочного сектора состоит из трех логических секторов 6, 7, и 8 тоже. В некоторых случаях Microsoft также использует сектор 12 зарезервированной области секторов для расширенного загрузчика.
		Информационный сектор FS (только FAT32)
		Больше зарезервированных секторов (необязательно)
FAT-регион	(количество FAT) * (секторов на FAT)	Таблица размещения файлов №1	Обычно он содержит две копии таблицы размещения файлов для проверки избыточности, хотя используется редко, даже утилитами восстановления диска. Это карты области данных, показывающие, какие кластеры используются файлами и каталогами. В FAT12 и FAT16 они следуют сразу за зарезервированными секторами. Обычно дополнительные копии строго синхронизируются при записи, а при чтении они используются только при возникновении ошибок в первой FAT. Первые два кластера (кластер 0 и 1 ) на карте содержат специальные значения.
		Таблица размещения файлов №2... (необязательно)
Регион корневого каталога	(количество корневых записей * 32) / (байты на сектор)	Корневой каталог (только FAT12 и FAT16)	Это таблица каталогов , в которой хранится информация о файлах и каталогах, расположенных в корневом каталоге. Он используется только с FAT12 и FAT16 и устанавливает для корневого каталога фиксированный максимальный размер, который предварительно выделяется при создании этого тома. FAT32 хранит корневой каталог в области данных вместе с файлами и другими каталогами, что позволяет ему расти без таких ограничений. Таким образом, для FAT32 здесь начинается область данных.
Регион данных	(количество кластеров) * (секторов в кластере)	Область данных (для файлов и каталогов) ... (до конца раздела или диска)	Здесь хранятся фактические данные файлов и каталогов, и они занимают большую часть раздела. FAT32 обычно начинает таблицу корневого каталога с кластера номер 2: первого кластера области данных.

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

Площадь зарезервированных секторов

Загрузочный сектор

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

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

Byte offset	Length (bytes)	Contents
0x000	3	Jump instruction. If the boot sector has a valid signature residing in the last two bytes of the boot sector (tested by most boot loaders residing in the System BIOS or the MBR) and this volume is booted from, the prior boot loader will pass execution to this entry point with certain register values, and the jump instruction will then skip past the rest of the (non-executable) header. See Volume Boot Record. Since DOS 2.0, valid x86-bootable disks must start with either a short jump followed by a NOP (opstring sequence 0xEB 0x?? 0x90 as seen since DOS 3.0—and on DOS 1.1) or a near jump (0xE9 0x?? 0x?? as seen on most (Compaq, TeleVideo) DOS 2.x formatted disks as well as on some (Epson, Olivetti) DOS 3.1 disks). For backward compatibility MS-DOS, PC DOS and DR-DOS also accept a jump (0x69 0x?? 0x??) on removable disks. On hard disks, DR DOS additionally accepts the swapped JMPS sequence starting with a NOP (0x90 0xEB 0x??), whereas MS-DOS/PC DOS do not. (See below for Atari ST compatibility.) The presence of one of these opstring patterns (in combination with a test for a valid media descriptor value at offset 0x015) serves as indicator to DOS 3.3 and higher that some kind of BPB is present (although the exact size should not be determined from the jump target since some boot sectors contain private boot loader data following the BPB), while for DOS 1.x (and some DOS 3.0) volumes, they will have to fall back to the DOS 1.x method to detect the format via the media byte in the FAT (in logical sector 1).
0x003	8	OEM Name (padded with spaces 0x20). This value determines in which system the disk was formatted. Although officially documented as free for OEM use, MS-DOS/PC DOS (since 3.1), Windows 95/98/SE/ME and OS/2 check this field to determine which other parts of the boot record can be relied upon and how to interpret them. Therefore, setting the OEM label to arbitrary or bogus values may cause MS-DOS, PC DOS and OS/2 to not recognize the volume properly and cause data corruption on writes. Common examples are "IBM␠␠3.3", "MSDOS5.0", "MSWIN4.1", "IBM␠␠7.1", "mkdosfs␠", and "FreeDOS␠". Some vendors store licensing info or access keys in this entry. The Volume Tracker in Windows 95/98/SE/ME will overwrite the OEM label with "?????IHC" signatures (a left-over from "␠OGACIHC" for "Chicago") even on a seemingly read-only disk access (such as a DIR A:) if the medium is not write-protected. Given the dependency on certain values explained above, this may, depending on the actual BPB format and contents, cause MS-DOS/PC DOS and OS/2 to no longer recognize a medium and throw error messages despite the fact that the medium is not defective and can still be read without problems under other operating systems. Windows 9x reads that self-marked disks without any problems but giving some strange values for non-meaning parameters which not exist or are not used when the disk was formatted with older BPB specification, e.g. disk serial number (which exists only for disks formatted on DOS 5.0 or later, and in Windows 9x after overwriting OEM label with ?????IHC will report it as 0000-0000 or any other value stored in disk serial number field when using disk formatted on other system). This applies only to removable disk drives. Some boot loaders make adjustments or refuse to pass control to a boot sector depending on certain values detected here (e.g., NEWLDR offset 0x018). The boot ROM of the Wang Professional Computer will only treat a disk as bootable if the first four characters of the OEM label are "Wang". Similarly, the ROM BIOS of the Philips :YES will only boot from a disk if the first four characters of the OEM label are ":YES". If, in an FAT32 EBPB, the signature at sector offset 0x042 is 0x29 and both total sector entries are 0, the file system entry may serve as a 64-bit total sector count entry and the OEM label entry may be used as alternative file system type instead of the normal entry at offset 0x052. In a similar fashion, if this entry is set to "EXFAT␠␠␠", it indicates the usage of an exFAT BPB located at sector offset 0x040 to 0x077, whereas NTFS volumes use "NTFS␠␠␠␠" to indicate an NTFS BPB.
0x00B	varies	BIOS Parameter Block (13, 19, 21 or 25 bytes), Extended BIOS Parameter Block (32 or 51 bytes) or FAT32 Extended BIOS Parameter Block (60 or 79 bytes); size and contents varies between operating systems and versions, see below
varies	varies	File system and operating system specific boot code; often starts immediately behind [E]BPB, but sometimes additional "private" boot loader data is stored between the end of the [E]BPB and the start of the boot code; therefore the jump at offset 0x001 cannot be used to reliably derive the exact [E]BPB format from. (In conjunction with at least a DOS 3.31 BPB some GPT boot loaders (like BootDuet) use 0x1FA–0x1FD to store the high 4 bytes of the hidden sectors for volumes located outside the first 232-1 sectors. Since this location may contain code or other data in other boot sectors, it may not be written to when 0x1F9–0x1FD do not all contain zero.)
0x1FD	1	Physical drive number (only in DOS 3.2 to 3.31 boot sectors). With OS/2 1.0 and DOS 4.0, this entry moved to sector offset 0x024 (at offset 0x19 in the EBPB). Most Microsoft and IBM boot sectors maintain values of 0x00 at offset 0x1FC and 0x1FD ever since, although they are not part of the signature at 0x1FE. If this belongs to a boot volume, the DR-DOS 7.07 enhanced MBR can be configured (see NEWLDR offset 0x014) to dynamically update this entry to the DL value provided at boot time or the value stored in the partition table. This enables booting off alternative drives, even when the VBR code ignores the DL value.
0x1FE	2	Boot sector signature (0x55 0xAA). This signature indicates an IBM PC compatible boot code and is tested by most boot loaders residing in the System BIOS or the MBR before passing execution to the boot sector's boot code (but, e.g., not by the original IBM PC ROM-BIOS). This signature does not indicate a particular file system or operating system. Since this signature is not present on all FAT-formatted disks (e.g., not on DOS 1.x or non-x86-bootable FAT volumes), operating systems must not rely on this signature to be present when logging in volumes (old issues of MS-DOS/PC DOS prior to 3.3 checked this signature, but newer issues as well as DR-DOS do not). Formatting tools must not write this signature if the written boot sector does not contain at least an x86-compatible dummy boot loader stub; at minimum, it must halt the CPU in an endless loop (0xF4 0xEB 0xFD) or issue an INT 19h and RETF (0xCD 0x19 0xCB). These opstrings should not be used at sector offset 0x000, however, because DOS tests for other opcodes as signatures. Many MSX-DOS 2 floppies use 0xEB 0xFE 0x90 at sector offset 0x000 to catch the CPU in a tight loop while maintaining an opcode pattern recognized by MS-DOS/PC DOS. This signature must be located at fixed sector offset 0x1FE for sector sizes 512 or higher. If the physical sector size is larger, it may be repeated at the end of the physical sector. Atari STs will assume a disk to be Atari 68000 bootable if the checksum over the 256 big-endian words of the boot sector equals 0x1234. If the boot loader code is IBM compatible, it is important to ensure that the checksum over the boot sector does not match this checksum by accident. If this would happen to be the case, changing an unused bit (e.g., before or after the boot code area) can be used to ensure this condition is not met. In rare cases, a reversed signature 0xAA 0x55 has been observed on disk images. This can be the result of a faulty implementation in the formatting tool based on faulty documentation, but it may also indicate a swapped byte order of the disk image, which might have occurred in transfer between platforms using a different endianness. BPB values and FAT12, FAT16 and FAT32 file systems are meant to use little-endian representation only and there are no known implementations of variants using big-endian values instead.

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

Byte offset	Length (bytes)	Contents
0x000	2	Jump instruction. Original Atari ST boot sectors start with a 68000 BRA.S instruction (0x60 0x??). For compatibility with PC operating systems, Atari ST formatted disks since TOS 1.4 start with 0xE9 0x?? instead.
0x002	6	OEM Name (padded with spaces 0x20), e.g., "Loader" (0x4C 0x6F 0x61 0x64 0x65 0x72) on volumes containing an Atari ST boot loader. See OEM Name precautions for PC formatted disks above. The offset and length of this entry are different compared to the entry on PC formatted disks.
0x008	3	Disk serial number (default: 0x00 0x00 0x00), used by Atari ST to detect a disk change. (Windows 9x Volume Tracker will always store "IHC" here on non-write-protected floppy disks; see above.) This value must be changed if the disk content is externally changed, otherwise Atari STs may not recognize the change on re-insertion. This entry overlaps the OEM Name field on PC formatted disks. For maximum compatibility, it may be necessary to match certain patterns here; see above.
0x00B	19	DOS 3.0 BIOS Parameter Block (little-endian format)
0x01E	varies	Private boot sector data (mixed big-endian and little-endian format)
varies	varies	File system and operating system specific Atari ST boot code. No assumptions must be made in regard to the load position of the code, which must be relocatable. If loading an operating system (TOS.IMG) fails, the code can return to the Atari ST BIOS with a 68000 RTS (opcode 0x4E75 with big-endian byte sequence 0x4E 0x75) instruction and all registers unaltered.
0x1FE	2	Checksum. The 16-bit checksum over the 256 big-endian words of the 512 bytes boot sector including this word must match the magic value 0x1234 in order to indicate an Atari ST 68000 executable boot sector code. This checksum entry can be used to align the checksum accordingly. If the logical sector size is larger than 512 bytes, the remainder is not included in the checksum and is typically zero-filled. Since some PC operating systems erroneously do not accept FAT formatted floppies if the 0x55 0xAA signature is not present here, it is advisable to place the 0x55 0xAA in this place (and add an IBM compatible boot loader or stub) and use an unused word in the private data or the boot code area or the serial number in order to ensure that the checksum 0x1234 is not matched (unless the shared fat code overlay would be both IBM PC and Atari ST executable at the same time).

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

Byte offset	Length (bytes)	Contents
0x000	3	Dummy jump instruction (e.g., 0xEB 0xFE 0x90).
0x003	8	OEM Name (padded with spaces 0x20).
0x00B	19	DOS 3.0 BPB
0x01E	varies (2)	MSX-DOS 1 code entry point for Z80 processors into MSX boot code. This is where MSX-DOS 1 machines jump to when passing control to the boot sector. This location overlaps with BPB formats since DOS 3.2 or the x86 compatible boot sector code of IBM PC compatible boot sectors and will lead to a crash on the MSX machine unless special precautions have been taken such as catching the CPU in a tight loop here (opstring 0x18 0xFE for JR 0x01E).
0x020	6	MSX-DOS 2 volume signature "VOL_ID".
0x026	1	MSX-DOS 2 undelete flag (default: 0x00. If the "VOL_ID" signature is present at sector offset 0x020, this flag indicates, if the volume holds deleted files which can be undeleted (see offset 0x0C in directory entries).
0x027	4	MSX-DOS 2 disk serial number (default: 0x00000000). If the "VOL_ID" signature is present at sector offset 0x020, MSX-DOS 2 stores a volume serial number here for media change detection.
0x02B	5	reserved
0x030	varies (2)	MSX-DOS 2 code entry point for Z80 processors into MSX boot code. This is where MSX-DOS 2 machines jump to when passing control to the boot sector. This location overlaps with EBPB formats since DOS 4.0 / OS/2 1.2 or the x86 compatible boot sector code of IBM PC compatible boot sectors and will lead to a crash on the MSX machine unless special precautions have been taken such as catching the CPU in a tight loop here (opstring 0x18 0xFE for JR 0x030).
0x1FE	2	Signature

Блок параметров BIOS

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

Sector offset	BPB offset	Length (bytes)	Contents
0x00B	0x00	2	Bytes per logical sector; the most common value is 512. Some operating systems don't support other sector sizes. For simplicity and maximum performance, the logical sector size is often identical to a disk's physical sector size, but can be larger or smaller in some scenarios. The minimum allowed value for non-bootable FAT12/FAT16 volumes with up to 65,535 logical sectors is 32 bytes, or 64 bytes for more than 65,535 logical sectors. The minimum practical value is 128. Some pre-DOS 3.31 OEM versions of DOS used logical sector sizes up to 8192 bytes for logical sectored FATs. Atari ST GEMDOS supports logical sector sizes between 512 and 4096. DR-DOS supports booting off FAT12/FAT16 volumes with logical sector sizes up to 32 KB and INT 13h implementations supporting physical sectors up to 1024 bytes/sector. The minimum logical sector size for standard FAT32 volumes is 512 bytes, which can be reduced downto 128 bytes without support for the FS Information Sector. Floppy drives and controllers use physical sector sizes of 128, 256, 512 and 1024 bytes (e.g., PC/AX). The Atari Portfolio supports a sector size of 512 for volumes larger than 64 KB, 256 bytes for volumes larger 32 KB and 128 bytes for smaller volumes. Magneto-optical drives used sector sizes of 512, 1024 and 2048 bytes. In 2005 some Seagate custom hard disks used sector sizes of 1024 bytes instead of the default 512 bytes. Advanced Format hard disks use 4096 bytes per sector (4Kn) since 2010, but will also be able to emulate 512 byte sectors (512e) for a transitional period. Linux, and by extension Android, supports a logical sector size far larger, officially documented in the Man page for the filesystem utilities as up to 32KB.
0x00D	0x02	1	Logical sectors per cluster. Allowed values are 1, 2, 4, 8, 16, 32, 64, and 128. Some MS-DOS 3.x versions supported a maximum cluster size of 4 KB only, whereas modern MS-DOS/PC DOS and Windows 95 support a maximum cluster size of 32 KB. Windows 98/SE/ME partially support a cluster size of 64 KB as well, but some FCB services are not available on such disks and various applications fail to work. The Windows NT family and some alternative DOS versions such as PTS-DOS fully support 64 KB clusters. For most DOS-based operating systems, the maximum cluster size remains at 32 KB (or 64 KB) even for sector sizes larger than 512 bytes. For logical sector sizes of 1 KB, 2 KB and 4 KB, Windows NT 4.0 supports cluster sizes of 128 KB, while for 2 KB and 4 KB sectors the cluster size can reach 256 KB. Some versions of DR-DOS provide limited support for 128 KB clusters with 512 bytes/sector using a sectors/cluster value of 0. MS-DOS/PC DOS will hang on startup if this value is erroneously specified as 0.
0x00E	0x03	2	Count of reserved logical sectors. The number of logical sectors before the first FAT in the file system image. At least 1 for this sector, usually 32 for FAT32 (to hold the extended boot sector, FS info sector and backup boot sectors). Since DR-DOS 7.0x FAT32 formatted volumes use a single-sector boot sector, FS info sector and backup sector, some volumes formatted under DR-DOS use a value of 4 here.
0x010	0x05	1	Number of File Allocation Tables. Almost always 2; RAM disks might use 1. Most versions of MS-DOS/PC DOS do not support more than 2 FATs. Some DOS operating systems support only two FATs in their built-in disk driver, but support other FAT counts for block device drivers loaded later on. Volumes declaring 2 FATs in this entry will never be treated as TFAT volumes. If the value differs from 2, some Microsoft operating systems may attempt to mount the volume as a TFAT volume and use the second cluster (cluster 1) of the first FAT to determine the TFAT status.
0x011	0x06	2	Maximum number of FAT12 or FAT16 root directory entries. 0 for FAT32, where the root directory is stored in ordinary data clusters; see offset 0x02C in FAT32 EBPBs. A value of 0 without a FAT32 EBPB (no signature 0x29 or 0x28 at offset 0x042) may also indicate a variable-sized root directory in some non-standard FAT12 and FAT16 implementations, which store the root directory start cluster in the cluster 1 entry in the FAT. This extension, however, is not supported by mainstream operating systems, as it can conflict with other uses of the cluster 1 entry for maintenance flags, the current end-of-chain-marker, or TFAT extensions. This value must be adjusted so that directory entries always consume full logical sectors, given that each directory entry takes up 32 bytes. MS-DOS/PC DOS require this value to be a multiple of 16. The maximum value supported on floppy disks is 240, the maximum value supported by MS-DOS/PC DOS on hard disks is 512. DR-DOS supports booting off FAT12/FAT16 volumes, if the boot file is located in the first 2048 root directory entries.
0x013	0x08	2	Total logical sectors. 0 for FAT32. (If zero, use 4 byte value at offset 0x020)
0x015	0x0A	1	Media descriptor (compare: FAT ID): 0xE5 8-inch (200 mm) single sided, 77 tracks per side, 26 sectors per track, 128 bytes per sector (250.25 KB) (DR-DOS only) 0xED 5.25-inch (130 mm) double sided, 80 tracks per side, 9 sector, 720 KB (Tandy 2000 only) 0xEE Designated for non-standard custom partitions (utilizing non-standard BPB formats or requiring special media access such as 48-/64-bit addressing); corresponds with 0xF8, but not recognized by unaware systems by design; value not required to be identical to FAT ID, never used as cluster end-of-chain marker (Reserved for DR-DOS) 0xEF Designated for non-standard custom superfloppy formats; corresponds with 0xF0, but not recognized by unaware systems by design; value not required to be identical to FAT ID, never used as cluster end-of-chain marker (Reserved for DR-DOS) 0xF0 3.5-inch (90 mm) double sided, 80 tracks per side, 18 or 36 sectors per track (1440 KB, known as "1.44 MB"; or 2880 KB, known as "2.88 MB"). Designated for use with custom floppy and superfloppy formats where the geometry is defined in the BPB. Used also for other media types such as tapes. 0xF4 Double density (Altos MS-DOS 2.11 only) 0xF5 Fixed disk, 4-sided, 12 sectors per track (1.95? MB) (Altos MS-DOS 2.11 only) 0xF8 Fixed disk (i.e., typically a partition on a hard disk). (since DOS 2.0) Designated to be used for any partitioned fixed or removable media, where the geometry is defined in the BPB. 3.5-inch single sided, 80 tracks per side, 9 sectors per track (360 KB) (MS-DOS 3.1 and MSX-DOS) 5.25-inch double sided, 80 tracks per side, 9 sectors per track (720 KB) (Sanyo 55x DS-DOS 2.11 only) Single sided (Altos MS-DOS 2.11 only) 0xF9 3.5-inch double sided, 80 tracks per side, 9 sectors per track (720 KB) (since DOS 3.2) 3.5-inch double sided, 80 tracks per side, 18 sectors per track (1440 KB) (DOS 3.2 only) 5.25-inch double sided, 80 tracks per side, 15 sectors per track (1200 KB, known as "1.2 MB") (since DOS 3.0) Single sided (Altos MS-DOS 2.11 only) 0xFA 3.5-inch and 5.25-inch single sided, 80 tracks per side, 8 sectors per track (320 KB) Used also for RAM disks and ROM disks (e.g., on Columbia Data Products and on HP 200LX) Hard disk (Tandy MS-DOS only) 0xFB 3.5-inch and 5.25-inch double sided, 80 tracks per side, 8 sectors per track (640 KB) 0xFC 5.25-inch single sided, 40 tracks per side, 9 sectors per track (180 KB) (since DOS 2.0) 0xFD 5.25-inch double sided, 40 tracks per side, 9 sectors per track (360 KB) (since DOS 2.0) 8-inch double sided, 77 tracks per side, 26 sectors per track, 128 bytes per sector (500.5 KB) (8-inch double sided, (single and) double density (DOS 1)) 0xFE 5.25-inch single sided, 40 tracks per side, 8 sectors per track (160 KB) (since DOS 1.0) 8-inch single sided, 77 tracks per side, 26 sectors per track, 128 bytes per sector (250.25 KB) 8-inch double sided, 77 tracks per side, 8 sectors per track, 1024 bytes per sector (1232 KB) (8-inch single sided, (single and) double density (DOS 1)) 0xFF 5.25-inch double sided, 40 tracks per side, 8 sectors per track (320 KB) (since DOS 1.1) Hard disk (Sanyo 55x DS-DOS 2.11 only) This value must reflect the media descriptor stored (in the entry for cluster 0) in the first byte of each copy of the FAT. Certain operating systems before DOS 3.2 (86-DOS, MS-DOS/PC DOS 1.x and MSX-DOS version 1.0) ignore the boot sector parameters altogether and use the media descriptor value from the first byte of the FAT to choose among internally pre-defined parameter templates. Must be greater or equal to 0xF0 since DOS 4.0. On removable drives, DR-DOS will assume the presence of a BPB if this value is greater or equal to 0xF0, whereas for fixed disks, it must be 0xF8 to assume the presence of a BPB. Initially, these values were meant to be used as bit flags; for any removable media without a recognized BPB format and a media descriptor of either 0xF8 or 0xFA to 0xFF MS-DOS/PC DOS treats bit 1 as a flag to choose a 9-sectors per track format rather than an 8-sectors format, and bit 0 as a flag to indicate double-sided media. Values 0x00 to 0xEF and 0xF1 to 0xF7 are reserved and must not be used.
0x016	0x0B	2	Logical sectors per File Allocation Table for FAT12/FAT16. FAT32 sets this to 0 and uses the 32-bit value at offset 0x024 instead.

ДОС 3.0 БПБ:

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

Смещение сектора	Смещение BPB	Длина (байты)	показывать Содержание
0x00B	0x00	13	DOS 2.0 BPB
0x018	0x0D	2	Physical sectors per track for disks with INT 13h CHS geometry, e.g., 15 for a "1.20 MB" (1200 KB) floppy. A zero entry indicates that this entry is reserved, but not used.
0x01A	0x0F	2	Number of heads for disks with INT 13h CHS geometry, e.g., 2 for a double sided floppy. A bug in all versions of MS-DOS/PC DOS up to including 7.10 causes these operating systems to crash for CHS geometries with 256 heads, therefore almost all BIOSes choose a maximum of 255 heads only. A zero entry indicates that this entry is reserved, but not used.
0x01C	0x11	2	Count of hidden sectors preceding the partition that contains this FAT volume. This field should always be zero on media that are not partitioned. This DOS 3.0 entry is incompatible with a similar entry at offset 0x01C in BPBs since DOS 3.31. It must not be used if the logical sectors entry at offset 0x013 is zero.

ДОС 3.2 БПБ:

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

Смещение сектора	Смещение BPB	Длина (байты)	Содержание
0x00B	0x00	19	ДОС 3.0 БПБ
0x01E	0x13	2	Всего логических секторов, включая скрытые сектора. Эта запись DOS 3.2 несовместима с аналогичной записью по смещению. 0x020 в BPB, начиная с DOS 3.31. Его нельзя использовать, если запись логического сектора по смещению 0x013 равен нулю.

ДОС 3.31 БПБ:

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

Смещение сектора	Смещение BPB	Длина (байты)	показывать Содержание
0x00B	0x00	13	DOS 2.0 BPB
0x018	0x0D	2	Physical sectors per track for disks with INT 13h CHS geometry, e.g., 18 for a "1.44 MB" (1440 KB) floppy. Unused for drives, which don't support CHS access any more. Identical to an entry available since DOS 3.0. A zero entry indicates that this entry is reserved, but not used. A value of 0 may indicate LBA-only access, but may cause a divide-by-zero exception in some boot loaders, which can be avoided by storing a neutral value of 1 here, if no CHS geometry can be reasonably emulated.
0x01A	0x0F	2	Number of heads for disks with INT 13h CHS geometry, e.g., 2 for a double sided floppy. Unused for drives, which don't support CHS access any more. Identical to an entry available since DOS 3.0. A bug in all versions of MS-DOS/PC DOS up to including 7.10 causes these operating systems to crash for CHS geometries with 256 heads, therefore almost all BIOSes choose a maximum of 255 heads only. A zero entry indicates that this entry is reserved, but not used. A value of 0 may indicate LBA-only access, but may cause a divide-by-zero exception in some boot loaders, which can be avoided by storing a neutral value of 1 here, if no CHS geometry can be reasonably emulated.
0x01C	0x11	4	Count of hidden sectors preceding the partition that contains this FAT volume. This field should always be zero on media that are not partitioned. This DOS 3.31 entry is incompatible with a similar entry at offset 0x01C in DOS 3.0-3.3 BPBs. At least, it can be trusted if it holds zero, or if the logical sectors entry at offset 0x013 is zero. If this belongs to an Advanced Active Partition (AAP) selected at boot time, the BPB entry will be dynamically updated by the enhanced MBR to reflect the "relative sectors" value in the partition table, stored at offset 0x1B6 in the AAP or NEWLDR MBR, so that it becomes possible to boot the operating system from EBRs. (Some GPT boot loaders (like BootDuet) use boot sector offsets 0x1FA–0x1FD to store the high 4 bytes of a 64-bit hidden sectors value for volumes located outside the first 232−1 sectors.)
0x020	0x15	4	Total logical sectors (if greater than 65535; otherwise, see offset 0x013). This DOS 3.31 entry is incompatible with a similar entry at offset 0x01E in DOS 3.2-3.3 BPBs. Officially, it must be used only if the logical sectors entry at offset 0x013 is zero, but some operating systems (some old versions of DR DOS) use this entry also for smaller disks. For partitioned media, if this and the entry at 0x013 are both 0 (as seen on some DOS 3.x FAT16 volumes), many operating systems (including MS-DOS/PC DOS) will retrieve the value from the corresponding partition's entry (at offset 0xC) in the MBR instead. If both of these entries are 0 on volumes using a FAT32 EBPB with signature 0x29, values exceeding the 4,294,967,295 (232−1) limit (f.e. some DR-DOS volumes with 32-bit cluster entries) can use a 64-bit entry at offset 0x052 instead.

Простая формула переводит заданный номер кластера тома CN на логический номер сектора LSN:

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

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

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

Расширенный блок параметров BIOS

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

Смещение сектора	Смещение EBPB	Длина (байты)	показывать Содержание
0x00B	0x00	25	DOS 3.31 BPB
0x024	0x19	1	Physical drive number (0x00 for (first) removable media, 0x80 for (first) fixed disk as per INT 13h). Allowed values for possible physical drives depending on BIOS are 0x00-0x7E and 0x80-0xFE. Values 0x7F and 0xFF are reserved for internal purposes such as remote or ROM boot and should never occur on disk. Some boot loaders such as the MS-DOS/PC DOS boot loader use this value when loading the operating system, others ignore it altogether or use the drive number provided in the DL register by the underlying boot loader (e.g., with many BIOSes and MBRs). The entry is sometimes changed by the SYS command or it can be dynamically fixed up by the prior bootstrap loader in order to force the boot sector code to load the operating system from alternative physical disks than the default. A similar entry existed (only) in DOS 3.2 to 3.31 boot sectors at sector offset 0x1FD. If this belongs to a boot volume, the DR-DOS 7.07 enhanced MBR can be configured (see NEWLDR offset 0x014) to dynamically update this EBPB entry to the DL value provided at boot time or the value stored in the partition table. This enables booting off alternative drives, even when the VBR code ignores the DL value.
0x025	0x1A	1	Reserved; In some MS-DOS/PC DOS boot code used as a scratchpad for the INT 13h current head high byte for the assumed 16-bit word at offset 0x024. Some DR-DOS FAT12/FAT16 boot sectors use this entry as a scratchpad as well, but for different purposes. VGA-Copy stores a CRC over the system's ROM-BIOS in this location. Some boot managers use this entry to communicate the desired drive letter under which the volume should occur to operating systems such as OS/2 by setting bit 7 and specifying the drive number in bits 6-0 (C: = value 0, D: = value 1, ...). Since this normally affects the in-memory image of the boot sector only, this does not cause compatibility problems with other uses; In Windows NT used for CHKDSK flags (bits 7-2 always cleared, bit 1: disk I/O errors encountered, possible bad sectors, run surface scan on next boot, bit 0: volume is "dirty" and was not properly unmounted before shutdown, run CHKDSK on next boot). Should be set to 0 by formatting tools. See also: Bitflags in the second cluster entry in the FAT.
0x026	0x1B	1	Extended boot signature. (Should be 0x29 to indicate that an EBPB with the following 3 entries exists (since OS/2 1.2 and DOS 4.0). Can be 0x28 on some OS/2 1.0-1.1 and PC DOS 3.4 disks indicating an earlier form of the EBPB format with only the serial number following. MS-DOS/PC DOS 4.0 and higher, OS/2 1.2 and higher as well as the Windows NT family recognize both signatures accordingly.)
0x027	0x1C	4	Volume ID (serial number) Typically the serial number "xxxx-xxxx" is created by a 16-bit addition of both DX values returned by INT 21h/AH=2Ah (get system date) and INT 21h/AH=2Ch (get system time) for the high word and another 16-bit addition of both CX values for the low word of the serial number. Alternatively, some DR-DOS disk utilities provide a /# option to generate a human-readable time stamp "mmdd-hhmm" build from BCD-encoded 8-bit values for the month, day, hour and minute instead of a serial number.
0x02B	0x20	11	Partition Volume Label, padded with blanks (0x20), e.g., "NO␠NAME␠␠␠␠" Software changing the directory volume label in the file system should also update this entry, but not all software does. The partition volume label is typically displayed in partitioning tools since it is accessible without mounting the volume. Supported since OS/2 1.2 and MS-DOS 4.0 and higher. Not available if the signature at 0x026 is set to 0x28. This area was used by boot sectors of DOS 3.2 to 3.3 to store a private copy of the Disk Parameter Table (DPT) instead of using the INT 1Eh pointer to retrieve the ROM table as in later issues of the boot sector. The re-usage of this location for the mostly cosmetical partition volume label minimized problems if some older system utilities would still attempt to patch the former DPT.
0x036	0x2B	8	File system type, padded with blanks (0x20), e.g., "FAT12␠␠␠", "FAT16␠␠␠", "FAT␠␠␠␠␠" This entry is meant for display purposes only and must not be used by the operating system to identify the type of the file system. Nevertheless, it is sometimes used for identification purposes by third-party software and therefore the values should not differ from those officially used. Supported since OS/2 1.2 and MS-DOS 4.0 and higher. Not available if the signature at 0x026 is set to 0x28.

Расширенный блок параметров BIOS FAT32

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

Смещение сектора	Смещение FAT32 EBPB	Длина (байты)	показывать Содержание
0x00B	0x00	25	DOS 3.31 BPB
0x024	0x19	4	Logical sectors per file allocation table (corresponds with the old entry at offset 0x0B in the DOS 2.0 BPB). The byte at offset 0x026 in this entry should never become 0x28 or 0x29 in order to avoid any misinterpretation with the EBPB format under non-FAT32 aware operating systems. Fortunately, under normal circumstances (sector size of 512 bytes), this cannot happen, as a FAT32 file system has at most 0xffffff6 = 268435446 clusters. One Fat sector fits 512 / 4 = 128 cluster descriptors. So at most only ceil(268435446 / 128) = 2097152 = 0x200000 sectors would be needed, making third byte of the number of FAT sectors 0x20 at most, which is less than the forbidden 0x28 and 0x29 values.
0x028	0x1D	2	Drive description / mirroring flags (bits 3-0: zero-based number of active FAT, if bit 7 set. If bit 7 is clear, all FATs are mirrored as usual. Other bits reserved and should be 0.) DR-DOS 7.07 FAT32 boot sectors with dual LBA and CHS support utilize bits 15-8 to store an access flag and part of a message. These bits contain either bit pattern 0110:1111b (low-case letter 'o', bit 13 set for CHS access) or 0100:1111b (upper-case letter 'O', bit 13 cleared for LBA access). The byte is also used for the second character in a potential "No␠IBMBIO␠␠COM" error message (see offset 0x034), displayed either in mixed or upper case, thereby indicating which access type failed). Formatting tools or non-DR SYS-type tools may clear these bits, but other disk tools should leave bits 15-8 unchanged.
0x02A	0x1F	2	Version (defined as 0.0). The high byte of the version number is stored at offset 0x02B, and the low byte at offset 0x02A. FAT32 implementations should refuse to mount volumes with version numbers unknown by them.
0x02C	0x21	4	Cluster number of root directory start, typically 2 (first cluster) if it contains no bad sector. (Microsoft's FAT32 implementation imposes an artificial limit of 65,535 entries per directory, whilst many third-party implementations do not.) A cluster value of 0 is not officially allowed and can never indicate a valid root directory start cluster. Some non-standard FAT32 implementations may treat it as an indicator to search for a fixed-sized root directory where it would be expected on FAT16 volumes; see offset 0x011.
0x030	0x25	2	Logical sector number of FS Information Sector, typically 1, i.e., the second of the three FAT32 boot sectors. Some FAT32 implementations support a slight variation of Microsoft's specification in making the FS Information Sector optional by specifying a value of 0xFFFF (or 0x0000) in this entry. Since logical sector 0 can never be a valid FS Information Sector, but FS Information Sectors use the same signature as found on many boot sectors , file system implementations should never attempt to use logical sector 0 as FS Information sector and instead assume that the feature is unsupported on that particular volume. Without a FS Information Sector, the minimum allowed logical sector size of FAT32 volumes can be reduced downto 128 bytes for special purposes.
0x032	0x27	2	First logical sector number of a copy of the three FAT32 boot sectors, typically 6. Since DR-DOS 7.0x FAT32 formatted volumes use a single-sector boot sector, some volumes formatted under DR-DOS use a value of 2 here. Values of 0x0000 (and/or 0xFFFF) are reserved and indicate that no backup sector is available.
0x034	0x29	12	Reserved (may be changed to format filler byte 0xF6 as an artifact by MS-DOS FDISK, must be initialized to 0 by formatting tools, but must not be changed by file system implementations or disk tools later on.) DR-DOS 7.07 FAT32 boot sectors use these 12 bytes to store the filename of the "IBMBIO␠␠COM" file to be loaded (up to the first 29,696 bytes or the actual file size, whatever is smaller) and executed by the boot sector, followed by a terminating NUL (0x00) character. This is also part of an error message, indicating the actual boot file name and access method (see offset 0x028).
0x040	0x35	1	Cf. 0x024 for FAT12/FAT16 (Physical Drive Number) exFAT BPBs are located at sector offset 0x040 to 0x077, overlapping all the remaining entries of a standard FAT32 EBPB including this one. They can be detected via their OEM label signature "EXFAT␠␠␠" at sector offset 0x003. In this case, the bytes at 0x00B to 0x03F are normally set to 0x00.
0x041	0x36	1	Cf. 0x025 for FAT12/FAT16 (Used for various purposes; see FAT12/FAT16) May hold format filler byte 0xF6 artifacts after partitioning with MS-DOS FDISK, but not yet formatted.
0x042	0x37	1	Cf. 0x026 for FAT12/FAT16 (Extended boot signature, 0x29) Most FAT32 file system implementations do not support an alternative signature of 0x28 to indicate a shortened form of the FAT32 EBPB with only the serial number following (and no Volume Label and File system type entries), but since these 19 mostly unused bytes might serve different purposes in some scenarios, implementations should accept 0x28 as an alternative signature and then fall back to use the directory volume label in the file system instead of in the EBPB for compatibility with potential extensions.
0x043	0x38	4	Cf. 0x027 for FAT12/FAT16 (Volume ID)
0x047	0x3C	11	Cf. 0x02B for FAT12/FAT16 (Volume Label) Not available if the signature at offset 0x042 is set to 0x28.
0x052	0x47	8	Cf. 0x036 for FAT12/FAT16 (File system type, padded with blanks (0x20), e.g., "FAT32␠␠␠"). Not available if the signature at 0x042 is set to 0x28. If both total logical sectors entries at offset 0x020 and 0x013 are 0 on volumes using a FAT32 EBPB with signature 0x29, volumes with more than 4,294,967,295 (232-1) sectors (f.e. some DR-DOS volumes with 32-bit cluster entries) can use this entry as 64-bit total logical sectors entry instead. In this case, the OEM label at sector offset 0x003 may be retrieved as new-style file system type instead.

Исключения

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

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

FAT ID (сравнить с идентификатором носителя по смещению BPB) 0x0A )	0xFF		0xFE			0xFD			0xFC	0xFB	0xFA	0xF9			0xF8			0xF0		0xED	показывать 0xE5
Size	8"	5.25"	8"	8"	5.25"	8"	8"	5.25"	5.25"	5.25" / 3.5"	5.25" / 3.5"	5.25"	3.5"	3.5"	5.25"	5.25" / 3.5"	3.5"	3.5"	3.5"	5.25"	8"
Density	?	DD 48tpi	SD	DD	DD 48tpi	SD	SD	DD 48tpi	DD 48tpi	?	?	HD 96tpi	DD 135tpi	HD 135tpi	QD 96tpi	?	DD	HD 135tpi	ED	QD 96tpi	SD
Modulation	?	MFM	FM	MFM	MFM	FM	FM	MFM	MFM	MFM	MFM	MFM	MFM	MFM	MFM	MFM	MFM	MFM	MFM	MFM	FM
Formatted capacity (KB)	?	320	250 ("old")	1200	160	250 ("new")	500	360	180	640	320	1200	720	1440	720	360	360	1440	2880	720	243 / 250
Cylinders (CHS)	77	40	77	77	40	77	77	40	40	80	80	80	80	80	80	80	80	80	80	80	77
Physical sectors / track (BPB offset 0x0D)	?	8	26	8	8	26	26	9	9	8	8	15	9	18	9 (8)	9	9	18	36	9 (8)	26
Number of heads (BPB offset 0x0F)	?	2	1	2 (1)	1	1	2	2	1	2	1	2	2	2	2	1	1	2	2	2	1
Byte payload / physical sector	?	512	128	1024	512	128	128	512	512	512	512	512	512	512	512	512	512	512	512	512	128
Bytes / logical sector (BPB offset 0x00)	?	512	128	1024	512	128	128	512	512	512	512	512	512	512	512	512	512	512	512	512	128
Logical sectors / cluster (BPB offset 0x02)	?	2	4	1	1	4	4	2	1	2	1 (2?)	1	2	1	?	2	?	1	2	?	4
Reserved logical sectors (BPB offset 0x03)	?	1	1	1	1	4	4	1	1	1	1	1	1 (2)	1	1	1	1	1	1	?	1
Number of FATs (BPB offset 0x05)	?	2	2	2	2	2	2	2	2	2	2	2	2	2	2	2	2	2	2	2	2
Root directory entries (BPB offset 0x06)	?	112 (7 sectors)	68 (17 sectors)	192 (6 sectors)	64 (4 sectors)	68 (17 sectors)	68 (17 sectors)	112 (7 sectors)	64 (4 sectors)	112 (7 sectors)	112 (7 sectors)	224 (14 sectors)	112 (7 sectors)	224 (14 sectors)	?	112 (7 sectors)	?	224 (14 sectors)	240 (15 sectors)	?	64 (16 sectors)
Total logical sectors (BPB offset 0x08)	?	640	2002	1232 (616)	320	2002	4004	720	360	1280	640	2400	1440	2880	?	720	?	2880	5760	?	2002
Logical sectors / FAT (BPB offset 0x0B)	?	1	6	2	1	6	6?	2	2	2	2 (1?)	7	3	9 (7)	?	2	?	9	9	?	1
Hidden sectors (BPB offset 0x11)	?	0	3 (0)	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	?	0
Total number of clusters	?	315	497	1227	313	?	997?	354	351	?	?	2371	713	2847?	?	?	?	2847	2863	?	?
Logical sector order	?	?	?	?	?	?	?	?	?	?	?	?	?	?	?	?	?	?	?	?	?
Sector mapping	?	sector+ head+ track+	sector+ head+ track+	sector+ head+ track+	sector+ head+ track+	sector+ track+	sector+ head+ track+	sector+ head+ track+	sector+ head+ track+	sector+ head+ track+	sector+ track+	sector+ head+ track+	sector+ head+ track+	sector+ head+ track+	?	sector+ track+	sector+ track+	sector+ head+ track+	sector+ head+ track+	?	sector+ track+
First physical sector (CHS)	?	1	1	1	1	1	1	1	1	?	?	1	1	1	?	1	?	1	1	?	1
DRIVER.SYS /F:n	?	0	3	4	0	?	3	0	0	?	?	1	2	7	?	?	?	7	9	?	3
BPB Presence	?	?	?	?	?	?	?	?	?	?	?	Yes	Yes	Yes	?	?	?	Yes	Yes	?	?
Support	?	DOS 1.1	DOS 1.0	DOS 2.0	DOS 1.0	?	DOS 2.0	DOS 2.0	DOS 2.0	?	?	DOS 3.0	DOS 3.2	DOS 3.2 only; (DR-DOS)	Sanyo 55x DS-DOS 2.11 only	MS-DOS 3.1	MSX-DOS	DOS 3.3	DOS 5.0	Tandy 2000 only	DR-DOS only

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

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

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

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

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

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

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

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 ID. 0xFA . Использование неформатированных дисков Вместо этого 0xE5 . Файловая система начинается с дорожки 2, стороны 0, сектора 1. В корневом каталоге имеется 2 копии FAT и 96 записей. Кроме того, существует преобразование физических дорожек в логические для осуществления чередования секторов 2:1. Диски были отформатированы с использованием физических секторов с номерами от 1 до 10 на каждой дорожке после зарезервированных дорожек, но логические сектора с 1 по 10 хранились в физических секторах 1, 6, 2, 7, 3, 8, 4, 9. , 5, 10.

Информационный сектор ФС

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

Компенсация обмена	Длина (байты)	скрывать Содержание
0x000	4	Подпись информационного сектора ФС ( 0x52 0x52 0x61 0x41 = " RRaA") Пока информационный сектор FS находится в логическом секторе 1, месте, где обычно запускается FAT в файловых системах FAT12 и FAT16 (только с одним зарезервированным сектором), наличие этой подписи гарантирует, что ранние версии DOS никогда не будут попытайтесь смонтировать том FAT32, поскольку они ожидают, что значения в кластере 0 и кластере 1 будут соответствовать определенным битовым шаблонам, которым не соответствует эта сигнатура.
0x004	480	Зарезервировано (значения байтов должны быть установлены на 0x00 во время форматирования, но на него нельзя полагаться и его нельзя изменить в дальнейшем)
0x1E4	4	Подпись информационного сектора ФС ( 0x72 0x72 0x41 0x61 = " rrAa")
0x1E8	4	Последнее известное количество свободных кластеров данных на томе или 0xFFFFFFFF, если неизвестно. Должно быть установлено 0xFFFFFFFF во время форматирования и позже обновляется операционной системой. Не следует полностью полагаться на точность во всех сценариях. Прежде чем использовать это значение, операционная система должна проверить, что это значение меньше или равно числу кластеров тома.
0x1EC	4	Номер кластера данных, который был выделен последним. Должно быть установлено 0xFFFFFFFF во время форматирования и позже обновляется операционной системой. С 0xFFFFFFFF система должна запуститься в кластере 0x00000002 . Не следует полностью полагаться на точность во всех сценариях. Прежде чем использовать это значение, операционная система должна проверить, что это значение является допустимым номером кластера на томе.
0x1F0	12	Зарезервировано (значения байтов должны быть установлены на 0x00 во время форматирования, но на него нельзя полагаться и его нельзя изменить в дальнейшем)
0x1FC	4	Подпись информационного сектора ФС ( 0x00 0x00 0x55 0xAA ) (Все четыре байта должны совпадать, прежде чем содержимое этого сектора будет считаться действительным.)

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

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

FAT-регион

Таблица размещения файлов

Карта кластера

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

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

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

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

Пример запуска таблицы FAT12 с несколькими цепочками кластеров

Компенсировать	+0	+1	+2	+3	+4	+5	+6	+7	+8	+9	+А	+Б	+С	+Д	+Э	+Ф
+0000	Ф0	Ф Ф	ФФ	03	40	00	05	60	00	07	80	00	ФФ	А Ф	00	14
+0010	С 0	00	0D	E0	00	0Ф	00	01	11	F0 0	ФФ	00	F0 0	ФФ	15	60
+0020	01	19	7 0	ФФ	F7	А Ф	01	ФФ	0 Ф	00	00	7 0	ФФ	00	00	00

• FAT ID /маркер порядка байтов (в зарезервированном кластере #0 ), где 0xF0 указывает том на неразмеченном диске супердискеты (должен быть 0xF8 для многораздельных дисков)
• Индикатор конца цепочки/флаги обслуживания (в зарезервированном кластере №1 )
• Вторая цепочка (7 кластеров) для нефрагментированного файла (здесь: №2, №3, №4, №5, №6, №7, №8).
• Третья цепочка (7 кластеров) для фрагментированного, возможно, выросшего файла (здесь: №9, №А, №14, №15, №16, №19, №1А).
• Четвертая цепочка (7 кластеров) для нефрагментированного, возможно, усеченного файла (здесь: #B, #C, #D, #E, #F, #10, #11)
• Пустые кластеры (здесь: №12, №1B, №1C, №1E, №1F)
• Пятая цепочка (1 кластер) для подкаталога (здесь: #13).
• Плохие кластеры (3 кластера) (здесь: №17, №18, №1D)

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

Пример запуска таблицы FAT16 с несколькими цепочками кластеров

Компенсировать	+0	+1	+2	+3	+4	+5	+6	+7	+8	+9	+А	+Б	+С	+Д	+Э	+Ф
+0000	Ф0	ФФ	ФФ	ФФ	03	00	04	00	05	00	06	00	07	00	08	00
+0010	ФФ	ФФ	0А	00	14	00	0С	00	0D	00	0Е	00	0Ф	00	10	00
+0020	11	00	ФФ	ФФ	00	00	ФФ	ФФ	15	00	16	00	19	00	F7	ФФ
+0030	F7	ФФ	1А	00	ФФ	ФФ	00	00	00	00	F7	ФФ	00	00	00	00

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

Пример запуска таблицы FAT32 с несколькими цепочками кластеров

Компенсировать	+0	+1	+2	+3	+4	+5	+6	+7	+8	+9	+А	+Б	+С	+Д	+Э	+Ф
+0000	Ф0	ФФ	ФФ	0Ф	ФФ	ФФ	ФФ	0Ф	ФФ	ФФ	ФФ	0Ф	04	00	00	00
+0010	05	00	00	00	06	00	00	00	07	00	00	00	08	00	00	00
+0020	ФФ	ФФ	ФФ	0Ф	0А	00	00	00	14	00	00	00	0С	00	00	00
+0030	0D	00	00	00	0Е	00	00	00	0Ф	00	00	00	10	00	00	00
+0040	11	00	00	00	ФФ	ФФ	ФФ	0Ф	00	00	00	00	ФФ	ФФ	ФФ	0Ф
+0050	15	00	00	00	16	00	00	00	19	00	00	00	F7	ФФ	ФФ	0Ф
+0060	F7	ФФ	ФФ	0Ф	1А	00	00	00	ФФ	ФФ	ФФ	0Ф	00	00	00	00
+0070	00	00	00	00	F7	ФФ	ФФ	0Ф	00	00	00	00	00	00	00	00

• Первая цепочка (1 кластер) для корневого каталога, на которую указывает запись в BPB FAT32 (здесь: № 2).
• Вторая цепочка (6 кластеров) для нефрагментированного файла (здесь: №3, №4, №5, №6, №7, №8).

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

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

Чтобы очень ранние версии DOS распознавали файловую систему, система должна быть загружена с тома, или FAT тома должна начинаться со второго сектора тома (логический сектор 1 с физическим адресом CHS 0/0/2 или адресом LBA 1). , то есть сразу после загрузочного сектора. Операционные системы предполагают это жесткое расположение FAT, чтобы найти идентификатор FAT в записи кластера 0 FAT на дискетах FAT DOS 1.0–1.1, где не найден действительный 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 старших бита равны нулю) этой записи всегда равны 1. Эти значения расположены так, чтобы запись также функционировала как ". «trap-all» маркер конца цепочки для всех кластеров данных, имеющих нулевое значение. Кроме того, для идентификаторов FAT, отличных от 0xFF (и 0x00 ) можно определить правильный порядок полубайтов и байтов (который будет использоваться) драйвером файловой системы, однако файловая система FAT официально использует только представление с прямым порядком байтов , и не существует известных реализаций вариантов, использующих обратный порядок байтов. вместо этого ценности. От 86-DOS 0.42 до MS-DOS 1.14 вместо FAT ID использовались профили жесткого диска, но этот байт использовался для различения носителей, отформатированных с помощью 32-байтовых или 16-байтовых записей каталога, поскольку они использовались до 86-DOS 0.42 до MS-DOS 1.14. ДОС 0.42.

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

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

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

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

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

Ценности кластера

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

FAT12	FAT16	FAT32	Описание
0x000	0x0000	0x?0000000	Бесплатный кластер; также используется DOS для ссылки на стартовый кластер родительского каталога в записях «..» подкаталогов корневого каталога на томах FAT12/FAT16. В противном случае, если это значение встречается в цепочках кластеров (например, в записях каталога нулевой длины или в удаленных файлах), реализации файловой системы должны рассматривать это как маркер конца цепочки.
0x001	0x0001	0x?0000001	Зарезервировано для внутренних целей; MS-DOS/PC DOS использует это значение кластера в качестве индикатора временного несвободного кластера при построении цепочек кластеров во время выделения файлов (видно только на диске, если в середине этого процесса произошел сбой или сбой питания). Если это значение встречается в цепочках кластеров на диске, реализации файловой системы должны рассматривать это как маркер конца цепочки.
0x002 - 0xFEF	0x0002 – 0xFFEF (0x0002 – 0x7FFF)	0x?0000002 - 0x?FFFFFFEF	Используется в качестве кластеров данных; значение указывает на следующий кластер. MS-DOS/PC DOS принимает значения до 0xFEF / 0xFFEF / 0x0FFFFFFEF (иногда больше; см. ниже), тогда как для Atari GEMDOS используются только значения до 0x7FFF разрешены на томах FAT16.
0xFF0 - 0xFF5 (0xFF1 - 0xFF5)	0xFFF0 - 0xFFF5	0x?FFFFFF0 - 0x?FFFFFF5	Зарезервировано в некоторых контекстах, или также используется как кластеры данных в некоторых нестандартных системах. Следует избегать размеров томов, в которых эти значения будут использоваться в качестве кластеров данных, но если эти значения встречаются в существующих томах, файловая система должна рассматривать их как обычные кластеры данных в цепочках кластеров (в идеале с применением дополнительных проверок работоспособности), аналогично тому, что MS- DOS, PC DOS и DR-DOS делают, и в противном случае следует избегать выделения их для файлов. MS-DOS/PC DOS 3.3 и выше обрабатывают значение 0xFF0 на томах FAT12 (но не на FAT16 или FAT32) в качестве дополнительного маркера конца цепи, аналогичного 0xFF8 - 0xFFF . Для совместимости с MS-DOS/PC DOS файловым системам следует избегать использования кластера данных. 0xFF0 в цепочках кластеров на томах FAT12 (то есть воспринимайте его как зарезервированный кластер, аналогичный 0xFF7 ). (Примечание. Соответствие младшего байта номера кластера значениям FAT ID и медиа-дескриптора является причиной того, почему эти значения кластера зарезервированы.)
0xFF6	0xFFF6	0x?FFFFFF6	Сдержанный; не используйте. (Примечание. Соответствует значению заполнителя формата по умолчанию. 0xF6 на IBM-совместимых компьютерах.) Не следует создавать тома, которые будут использовать это значение в качестве кластера данных, но если это значение встречается в существующих томах, файловая система должна рассматривать его как обычный кластер данных в цепочках кластеров (в идеале с применением дополнительных проверок работоспособности). ), и в противном случае следует избегать выделения его для файлов.
0xFF7	0xFFF7	0x?FFFFFF7	Плохой сектор в кластере или зарезервированном кластере (начиная с DOS 2.0). Значения переключения для максимального количества кластеров для файловых систем FAT12 и FAT16 определяются так, чтобы максимально возможные значения кластера данных ( 0xFF5 и 0xFFF5 , соответственно) всегда будет меньше этого значения. Следовательно, это значение обычно не может встречаться в цепочках кластеров, но если оно встречается, его можно рассматривать как обычный кластер данных, поскольку 0xFF7 мог быть нестандартным кластером данных на томах FAT12 до появления маркера плохого кластера в DOS 2.0 или появления FAT16 в DOS 3.0. и 0xFFF7 мог быть нестандартным кластером данных на томах FAT16 до появления FAT32 с DOS 7.10. Теоретически, 0x0FFFFFF7 может быть частью допустимой цепочки кластеров на томах FAT32, но дисковым утилитам следует избегать создания томов FAT32, где может возникнуть такое условие. Файловая система не должна выделять этот кластер для файлов. Дисковые утилиты не должны пытаться восстановить «потерянные кластеры», содержащие это значение в FAT, а считать их неисправными кластерами.
0xFF8 — 0xFFF (и опционально 0xFF0; см. примечание)	0xFFF8 - 0xFFFF	0x?FFFFFF8 - 0x?FFFFFFFF	Последний кластер в файле (EOC). Реализации файловой системы должны одновременно рассматривать все эти значения как маркеры конца цепочки. Большинство реализаций файловой системы (включая 86-DOS, MS-DOS, PC DOS и DR-DOS) используют 0xFFF / 0xFFFF / 0x0FFFFFFFF как маркер конца файла при выделении файлов, но используются версии Linux до 2.5.40. 0xFF8 / 0xFFF8 / 0x0FFFFFF8 . Версии mkdosfs ( dosfstools до 3.0.26) продолжают использовать 0x0FFFFFF8 для корневого каталога на томах FAT32, тогда как некоторые инструменты восстановления и дефрагментации диска используют другие значения в наборе (например, SCANDISK может использовать 0xFF8 / 0xFFF8 / вместо этого 0x0FFFFFF8 ). В то время как в исходной реализации 8-битной FAT в Microsoft Standalone Disk BASIC используются разные конечные маркеры ( 0xC0 .. 0xCD ) использовались для обозначения количества секторов (от 0 до 13), использованных в последнем кластере, занятом файлом, различные конечные маркеры были перепрофилированы в DOS для обозначения разных типов носителей, с используемым в настоящее время конечным маркером, указанным в записи кластера 1 , однако эта концепция, похоже, не нашла широкого применения на практике — и до такой степени, что в некоторых сценариях тома могут не распознаваться некоторыми операционными системами, если некоторые из младшие биты значения, хранящегося в кластере 1, не установлены. Кроме того, некоторые ошибочные реализации файловой системы принимают только 0xFFF / 0xFFFF / 0x?FFFFFFF как действительный маркер конца цепочки. Реализации файловой системы должны проверять значения кластера в цепочках кластеров на соответствие максимально допустимому значению кластера, рассчитанному по фактическому размеру тома, и обрабатывать более высокие значения, как если бы они также были маркерами конца цепочки. (Младший байт номера кластера концептуально соответствует значениям FAT ID и дескриптора носителя ; см. примечание выше для специального использования MS-DOS/PC DOS. 0xFF0 на томах FAT12. )

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

Область корневого каталога

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

Регион данных

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

Таблица каталогов

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

Сама файловая система FAT не накладывает никаких ограничений на глубину дерева подкаталогов, пока существуют свободные кластеры для размещения подкаталогов, однако внутренняя структура текущих каталогов (CDS) в MS-DOS/PC DOS ограничивает абсолютный путь к каталогу длиной до 66 символов (включая букву диска, но без учета байтового разделителя NUL), тем самым ограничивая максимальную поддерживаемую глубину подкаталогов до 32, что бы ни произошло раньше. Concurrent DOS, Multiuser DOS и DR DOS версий 3.31–6.0 (вплоть до обновлений 1992–11 гг.) не сохраняют внутри себя абсолютные пути к рабочим каталогам и, следовательно, не отображают это ограничение. То же самое относится и к Atari GEMDOS, но Atari Desktop не поддерживает более 8 уровней подкаталогов. Большинство приложений, знающих об этом расширении, поддерживают пути длиной не менее 127 байт. FlexOS, 4680 OS и 4690 OS также поддерживают длину до 127 байт, что позволяет уменьшить глубину до 60 уровней. PalmDOS, DR DOS 6.0 (начиная с BDOS 7.1) и выше, Novell DOS и OpenDOS имеют CDS, совместимый с MS-DOS, и поэтому имеют те же ограничения по длине, что и 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". Операционная система удалит один (а также две — начиная с DR-DOS 7.02) точки с запятой и ожидающие пароли из имен файлов перед их сохранением на диске. (Командный процессор 4DOS использует точки с запятой для включаемых списков и требует, чтобы точка с запятой удваивалась для файлов, защищенных паролем, с любыми командами, поддерживающими подстановочные знаки. )

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

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

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

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

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

• @ # ( ) { } $ &

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

Запись в каталоге

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

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

Компенсация обмена	Длина (байты)	показывать Содержание
0x00	8	Short file name (padded with spaces) The first byte can have the following special values: Value Description 0x00 Entry is available and no subsequent entry is in use. Also serves as an end marker when DOS scans a directory table. (Since MS-DOS 1.25 and PC DOS 2.0, not in earlier versions of MS-DOS, PC DOS, or 86-DOS. Instead, they will treat such entries as allocated. Therefore, this value must not be used as end marker, if a volume should remain accessible under PC DOS 1.0/1.1 as well.) 0x05 Initial character is actually 0xE5. (since DOS 3.0) Under DR DOS 6.0 and higher, including PalmDOS, Novell DOS and OpenDOS, 0x05 is also used for pending delete files under DELWATCH. Once they are removed from the deletion tracking queue, the first character of an erased file is replaced by 0xE5. 0x2E 'Dot' entry; either "." or ".." (since MS-DOS 1.40 and PC DOS 2.0) 0xE5 Entry has been previously erased and/or is available. File undelete utilities must replace this character with a regular character as part of the undeletion process. See also: 0x05. The value 0xE5 was chosen for this purpose in 86-DOS because 8-inch CP/M floppies came pre-formatted with this value filled and so could be used to store files out of the box. Versions of DOS prior to 5.0 start scanning directory tables from the top of the directory table to the bottom. In order to increase chances for successful file undeletion, DOS 5.0 and higher will remember the position of the last written directory entry and use this as a starting point for directory table scans.
0x08	3	Short file extension (padded with spaces)
0x0B	1	File Attributes Bit Mask Description 0 0x01 Read Only. (Since DOS 2.0) If this bit is set, the operating system will not allow a file to be opened for modification. Deliberately setting this bit for files which will not be written to (executables, shared libraries and data files) may help avoid problems with concurrent file access in multi-tasking, multi-user or network environments with applications not specifically designed to work in such environments (i.e. non-SHARE-enabled programs). The DCF digital camera file system standard utilizes the Read Only attribute to allow directories or individual files (DCF objects) to be marked as "protected" from deletion by the user. 1 0x02 Hidden. Hides files or directories from normal directory views. Under DR DOS 3.31 and higher, under PalmDOS, Novell DOS, OpenDOS, Concurrent DOS, Multiuser DOS, REAL/32, password protected files and directories also have the hidden attribute set. Password-aware operating systems should not hide password-protected files from directory views, even if this bit may be set. The password protection mechanism does not depend on the hidden attribute being set up to including DR-DOS 7.03, but if the hidden attribute is set, it should not be cleared for any password-protected files. 2 0x04 System. Indicates that the file belongs to the system and must not be physically moved (e.g., during defragmentation), because there may be references into the file using absolute addressing bypassing the file system (boot loaders, kernel images, swap files, extended attributes, etc.). 3 0x08 Volume Label. (Since MS-DOS 1.28 and PC DOS 2.0) Indicates an optional directory volume label, normally only residing in a volume's root directory. Ideally, the volume label should be the first entry in the directory (after reserved entries) in order to avoid problems with VFAT LFNs. If this volume label is not present, some systems may fall back to display the partition volume label instead, if an EBPB is present in the boot sector (not present with some non-bootable block device drivers, and possibly not writeable with boot sector write protection). Even if this volume label is present, partitioning tools like FDISK may display the partition volume label instead. The entry occupies a directory entry but has no file associated with it. Volume labels have a filesize entry of zero. Pending delete files and directories under DELWATCH have the volume attribute set until they are purged or undeleted. 4 0x10 Subdirectory. (Since MS-DOS 1.40 and PC DOS 2.0) Indicates that the cluster-chain associated with this entry gets interpreted as subdirectory instead of as a file. Subdirectories have a filesize entry of zero. 5 0x20 Archive. (Since DOS 2.0) Typically set by the operating system as soon as the file is created or modified to mark the file as "dirty", and reset by backup software once the file has been backed up to indicate "pure" state. 6 0x40 Device (internally set for character device names found in filespecs, never found on disk), must not be changed by disk tools. 7 0x80 Reserved, must not be changed by disk tools. Under DR DOS 6.0 and higher, including PalmDOS, Novell DOS and OpenDOS, the volume attribute is set for pending delete files and directories under DELWATCH. An attribute combination of 0x0F is used to designate a VFAT long file name entry since MS-DOS 7.0. Older versions of DOS can mistake this for a directory volume label, as they take the first entry with volume attribute set as volume label. This problem can be avoided if a directory volume label is enforced as part of the format process; for this reason some disk tools explicitly write dummy "NO␠NAME␠␠␠␠" directory volume labels when the user does not specify a volume label. Since volume labels normally don't have the system attribute set at the same time, it is possible to distinguish between volume labels and VFAT LFN entries. The attribute combination 0x0F could occasionally also occur as part of a valid pending delete file under DELWATCH, however on FAT12 and FAT16 volumes, VFAT LFN entries always have the cluster value at 0x1A set to 0x0000 and the length entry at 0x1C is never 0x00000000, whereas the entry at 0x1A is always non-zero for pending delete files under DELWATCH. This check does not work on FAT32 volumes.
0x0C	1	CP/M-86 and DOS Plus store user attributes F1'—F4' here. (DOS Plus 1.2 with BDOS 4.1 supports passwords only on CP/M media, not on FAT12 or FAT16 media. While DOS Plus 2.1 supported logical sectored FATs with a partition type 0xF2, FAT16B and FAT32 volumes were not supported by these operation systems. Even if a partition would have been converted to FAT16B it would still not be larger than 32 MB. Therefore, this usage does not conflict with FAT32.IFS, FAT16+ or FAT32+ as they can never occur on the same type of volume.): Bit Mask Description 7 0x80 F1': Modify default open rules 6 0x40 F2': Partial close default 5 0x20 F3': Ignore Close Checksum Error 4 0x10 F4': Disable checksums 3 0x08 Reserved 2 0x04 Delete requires password 1 0x02 Write requires password 0 0x01 Read requires password MSX-DOS 2: For a deleted file, the original first character of the filename. For the same feature in various other operating systems, see offset 0x0D if enabled in MSX boot sectors at sector offset 0x026. MSX-DOS supported FAT12 volumes only, but third-party extensions for FAT16 volumes exist. Therefore, this usage does not conflict with FAT32.IFS and FAT32+ below. It does not conflict with the usage for user attributes under CP/M-86 and DOS Plus as well, since they are no longer important for deleted files. Windows NT and later versions uses bits 3 and 4 to encode case information (see VFAT); otherwise 0. DR-DOS 7.0x reserved bits other than 3 and 4 for internal purposes since 1997. The value should be set to 0 by formatting tools and must not be changed by disk tools. On FAT32 volumes under OS/2 and eComStation the third-party FAT32.IFS driver utilizes this entry as a mark byte to indicate the presence of extra "␠EA.␠SF" files holding extended attributes with parameter /EAS. Version 0.70 to 0.96 used the magic values 0x00 (no EAs), 0xEA (normal EAs) and 0xEC (critical EAs), whereas version 0.97 and higher since 2003-09 use 0x00, 0x40 (normal EAs) and 0x80 (critical EAs) as bitflags for compatibility with Windows NT.
0x0D	1	First character of a deleted file under Novell DOS, OpenDOS and DR-DOS 7.02 and higher. A value of 0xE5 (229), as set by DELPURGE, will prohibit undeletion by UNDELETE, a value of 0x00 will allow conventional undeletion asking the user for the missing first filename character. S/DOS 1 and PTS-DOS 6.51 and higher also support this feature if enabled with SAVENAME=ON in CONFIG.SYS. For the same feature in MSX-DOS, see offset 0x0C. Create time, fine resolution: 10 ms units, values from 0 to 199 (since DOS 7.0 with VFAT). Double usage for create time ms and file char does not create a conflict, since the creation time is no longer important for deleted files.
0x0E	2	Under DR DOS 3.31 and higher including PalmDOS, Novell DOS and OpenDOS as well as under Concurrent DOS, Multiuser DOS, System Manager, and REAL/32 and possibly also under FlexOS, 4680 OS, 4690 OS any non-zero value indicates the password hash of a protected file, directory or volume label. The hash is calculated from the first eight characters of a password. If the file operation to be carried out requires a password as per the access rights bitmap stored at offset 0x14, the system tries to match the hash against the hash code of the currently set global password (by PASSWORD /G) or, if this fails, tries to extract a semicolon-appended password from the filespec passed to the operating system and checks it against the hash code stored here. A set password will be preserved even if a file is deleted and later undeleted. Create time (since DOS 7.0 with VFAT). The hour, minute and second are encoded according to the following bitmap: Bits Description 15-11 Hours (0–23) 10-5 Minutes (0–59) 4-0 Seconds/2 (0–29) The seconds is recorded only to a 2 second resolution. Finer resolution for file creation is found at offset 0x0D. If bits 15-11 > 23 or bits 10-5 > 59 or bits 4-0 > 29 here, or when bits 12-0 at offset 0x14 hold an access bitmap and this is not a FAT32 volume or a volume using OS/2 Extended Attributes, then this entry actually holds a password hash, otherwise it can be assumed to be a file creation time.
0x10	2	FlexOS, 4680 OS and 4690 OS store a record size in the word at entry 0x10. This is mainly used for their special database-like file types random file, direct file, keyed file, and sequential file. If the record size is set to 0 (default) or 1, the operating systems assume a record granularity of 1 byte for the file, for which it will not perform record boundary checks in read/write operations. With DELWATCH 2.00 and higher under Novell DOS 7, OpenDOS 7.01 and DR-DOS 7.02 and higher, this entry is used to store the last modified time stamp for pending delete files and directories. Cleared when file is undeleted or purged. See offset 0x0E for a format description. Create date (since DOS 7.0 with VFAT). The year, month and day are encoded according to the following bitmap: Bits Description 15-9 Year (0 = 1980, 119 = 2099 supported under DOS/Windows, theoretically up to 127 = 2107) 8-5 Month (1–12) 4-0 Day (1–31) The usage for creation date for existing files does not conflict with last modified time for deleted files because they are never used at the same time. For the same reason, the usage for the record size of existing files and last modified time of deleted files does not conflict. Creation dates and record sizes cannot be used at the same time, however, both are stored only on file creation and never changed later on, thereby limiting the conflict to FlexOS, 4680 OS and 4690 OS systems accessing files created under foreign operating systems as well as potential display or file sorting problems on systems trying to interpret a record size as creation time. To avoid the conflict, the storage of creation dates should be an optional feature of operating systems supporting it.
0x12	2	FlexOS, 4680 OS, 4690 OS, Multiuser DOS, System Manager, REAL/32 and DR DOS 6.0 and higher with multi-user security enabled use this field to store owner IDs. Offset 0x12 holds the user ID, 0x13 the group ID of a file's creator. In multi-user versions, system access requires a logon with account name and password, and the system assigns group and user IDs to running applications according to the previously set up and stored authorization info and inheritance rules. For 4680 OS and 4690 OS, group ID 1 is reserved for the system, group ID 2 for vendor, group ID 3 for the default user group. Background applications started by users have a group ID 2 and user ID 1, whereas operating system background tasks have group IDs 1 or 0 and user IDs 1 or 0. IBM 4680 BASIC and applications started as primary or secondary always get group ID 2 and user ID 1. When applications create files, the system will store their user ID and group ID and the required permissions with the file. With DELWATCH 2.00 and higher under Novell DOS 7, OpenDOS 7.01 and DR-DOS 7.02 and higher, this entry is used to store the last modified date stamp for pending delete files and directories. Cleared when file is undeleted or purged. See offset 0x10 for a format description. Last access date (since DOS 7.0 if ACCDATE enabled in CONFIG.SYS for the corresponding drive); see offset 0x10 for a format description. The usage for the owner IDs of existing files does not conflict with last modified date stamp for deleted files because they are never used at the same time. The usage of the last modified date stamp for deleted files does not conflict with access date since access dates are no longer important for deleted files. However, owner IDs and access dates cannot be used at the same time.
0x14	2	High two bytes of first cluster number in FAT32; with the low two bytes stored at offset 0x1A. Access rights bitmap for world/group/owner read/write/execute/delete protection for password protected files, directories (or volume labels) under DR DOS 3.31 and higher, including PalmDOS, Novell DOS and OpenDOS, and under FlexOS, 4680 OS, 4690 OS, Concurrent DOS, Multiuser DOS, System Manager, and REAL/32. Typical values stored on a single-user system are 0x0000 (PASSWORD /N for all access rights "RWED"), 0x0111 (PASSWORD /D for access rights "RW?-"), 0x0555 (PASSWORD /W for access rights "R-?-") and 0x0DDD (PASSWORD /R for files or PASSWORD /P for directories for access rights "--?-"). Bits 1, 5, 9, 12-15 will be preserved when changing access rights. If execute bits are set on systems other than FlexOS, 4680 OS or 4690 OS, they will be treated similar to read bits. (Some versions of PASSWORD allow to set passwords on volume labels (PASSWORD /V) as well.) Single-user systems calculate the most restrictive rights of the three sets (DR DOS up to 5.0 used bits 0-3 only) and check if any of the requested file access types requires a permission and if a file password is stored. If not, file access is granted. Otherwise the stored password is checked against an optional global password provided by the operating system and an optional file password provided as part of the filename separated by a semicolon (not under FlexOS, 4680 OS, 4690 OS). If neither of them is provided, the request will fail. If one of them matches, the system will grant access (within the limits of the normal file attributes, that is, a read-only file can still not be opened for write this way), otherwise fail the request. Under FlexOS, 4680 OS and 4690 OS the system assigns group and user IDs to applications when launched. When they request file access, their group and user IDs are compared with the group and user IDs of the file to be opened. If both IDs match, the application will be treated as file owner. If only the group ID matches, the operating system will grant group access to the application, and if the group ID does not match as well, it will grant world access. If an application's group ID and user ID are both 0, the operating system will bypass security checking. Once the permission class has been determined, the operating system will check if any of the access types of the requested file operation requires a permission according to the stored bitflags of the selected class owner, group or world in the file's directory entry. Owner, group and world access rights are independent and do not need to have diminishing access levels. Only, if none of the requested access types require a permission, the operating system will grant access, otherwise it fails. If multiuser file / directory password security is enabled the system will not fail at this stage but perform the password checking mechanism for the selected permission class similar to the procedure described above. With multi-user security loaded many utilities since DR DOS 6.0 will provide an additional /U:name parameter. File access rights bitmap: Bit Mask Description 0 0x0001 Owner delete/rename/attribute change requires permission 1 0x0002 Owner execute requires permission (FlexOS, 4680 OS, 4690 OS only) 2 0x0004 Owner write/modify requires permission 3 0x0008 Owner read/copy requires permission 4 0x0010 Group delete/rename/attribute change requires permission 5 0x0020 Group execute requires permission (FlexOS, 4680 OS, 4690 OS only) 6 0x0040 Group write/modify requires permission 7 0x0080 Group read/copy requires permission 8 0x0100 World delete/rename/attribute change requires permission 9 0x0200 World execute requires permission (FlexOS, 4680 OS, 4690 OS only) 10 0x0400 World write/modify requires permission 11 0x0800 World read/copy requires permission 12-15 bits must be set to 0 during format and must not be modified by disk tools later on; bit 15 is used internally, but not on disk File renames require either write or delete rights, IBM 4680 BASIC CHAIN requires execute rights. Extended Attributes handle (used by OS/2 1.2 and higher as well as by Windows NT) in FAT12 and FAT16; first cluster of EA file or 0, if not used. A different method to store extended attributes has been devised for FAT32 volumes, see FAT32.IFS under offset 0x0C. The storage of the high two bytes of the first cluster in a file on FAT32 partially conflicts with access rights bitmaps.
0x16	2	Last modified time (since PC DOS 1.1/MS-DOS 1.20); see offset 0x0E for a format description. Under Novell DOS, OpenDOS and DR-DOS 7.02 and higher, this entry holds the deletion time of pending delete files or directories under DELWATCH 2.00 or higher. The last modified time stamp is copied to 0x10 for possible later restoration. See offset 0x0E for a format description.
0x18	2	Last modified date; see offset 0x10 for a format description. Under Novell DOS, OpenDOS and DR-DOS 7.02 and higher, this entry holds the deletion date of pending delete files or directories under DELWATCH 2.00 or higher. The last modified date stamp is copied to 0x12 for possible later restoration. See offset 0x10 for a format description.
0x1A	2	Start of file in clusters in FAT12 and FAT16. Low two bytes of first cluster in FAT32; with the high two bytes stored at offset 0x14. Entries with the Volume Label flag, subdirectory ".." pointing to the FAT12 and FAT16 root, and empty files with size 0 should have first cluster 0. VFAT LFN entries also have this entry set to 0; on FAT12 and FAT16 volumes this can be used as part of a detection mechanism to distinguish between pending delete files under DELWATCH and VFAT LFNs; see above.
0x1C	4	File size in bytes. Entries with the Volume Label or Subdirectory flag set should have a size of 0. VFAT LFN entries never store the value 0x00000000 here. This can be used as part of a detection mechanism to distinguish between pending delete files under DELWATCH and VFAT LFNs; see above.

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

1. Локальный: не распространять файл, а хранить только на локальном контроллере.
2. Зеркальное отображение файла при обновлении: Распространять файл на сервер только при обновлении файла.
3. Зеркальное отображение файла при закрытии: Распространять файл на сервер только после закрытия файла.
4. Составной файл при обновлении: Распространение файла на все контроллеры при обновлении файла.
5. Составной файл при закрытии: Распространение файла на все контроллеры при закрытии файла.

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

Компенсация обмена	Длина (байты)	Система	показывать Описание
0x0C	2	RISC OS	File type, 0x0000–0x0FFF
0x0C	4	Petrov DOSFS	File load address
0x0E	2	ANDOS	File address in the memory
0x10	4	Petrov DOSFS	File execution address

Ограничения по размеру

Варианты файловых систем 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: от 65 525 до 268 435 444 кластеров: от 512 до 2 097 152 секторов на копию FAT

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

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

Максимум FAT16: 64 сектора на кластер × 65 524 кластера = 2 147 090 432 байта (≈2 047 МБ)
[Максимум 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 не используется. Аналогично 65524+3 0xFFF7 для FAT16 и 4084+3 0xFF7 для FAT12. Количество секторов в кластере — это степень 2, умещающаяся в один байт, наименьшее значение — 1 ( 0x01 ), самое большое значение — 128 ( 0x80 ). Линии в квадратных скобках обозначают необычный размер кластера 128, а для FAT32 — больший, чем необходимо, размер кластера 32 или 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 байт. ДОС 5 RMDIR/ RD команда удаляет начальный " ." (этот каталог) и " .." (родительский каталог) записи непосредственно в подкаталогах, поэтому размер сектора 32 на RAM-диске возможен для FAT12, но требует 2 или более секторов на кластер. Загрузочный сектор FAT12 без расширений DOS 4 требует 29 байт перед первым ненужным FAT16B 32 -битное количество скрытых секторов, это оставляет три байта для (на неиспользуемом RAM-диске) загрузочного кода и магического 0x55 0xAA в конце всех загрузочных секторов. В Windows NT наименьший поддерживаемый размер сектора — 128.

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

Обе версии каждого ECMA-107. и ИСО/МЭК 9293 укажите максимальное число кластеров MAX определяется по формуле MAX=1+trunc((TS-SSA)/SC)и зарезервируйте номера кластеров MAX+1 до 4086 ( 0xFF6 , FAT12) и более поздних версий 65526 ​​( 0xFFF6 , FAT16) для будущей стандартизации.

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

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

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

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

Фрагментация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также: Фрагментация файловой системы.

Длинные имена файлов VFAT

Структура каталогов FAT32 с тремя файлами, два из которых используют длинные имена файлов VFAT.

Длинные имена файлов VFAT (LFN) сохраняются в файловой системе FAT с помощью хитрости: добавление дополнительных записей в каталог перед обычной записью файла. Дополнительные записи помечаются атрибутами «Метка тома», «Система», «Скрытый» и «Только чтение» (что дает 0x0F ), эта комбинация не ожидается в среде MS-DOS и поэтому игнорируется программами MS-DOS и сторонними утилитами. Примечательно, что каталог, содержащий только метки томов, считается пустым и его можно удалить; такая ситуация возникает, если файлы, созданные с длинными именами, удаляются из обычного DOS. Этот метод очень похож на метод DELWATCH, позволяющий использовать атрибут тома для сокрытия файлов, ожидающих удаления, для возможного восстановления в будущем, начиная с DR DOS 6.0 (1991) и выше. Это также похоже на публично обсуждавшийся метод хранения длинных имен файлов в Ataris и Linux в 1992 году.

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

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

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

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

Компенсация обмена	Длина (байты)	скрывать Описание
0x00	1	Порядковый номер (бит 6: последняя логическая, первая физическая запись LFN, бит 5: 0; биты 4–0: номер 0x01 .. 0x14 ( 0x1F ), удалена запись: 0xE5 )
0x01	10	Символы имени (пять UCS-2 символов )
0x0B	1	Атрибуты (всегда 0x0F )
0x0C	1	Тип (всегда 0x00 для VFAT LFN, остальные значения зарезервированы для использования в будущем; информацию об особом использовании битов 4 и 3 в SFN см. выше)
0x0D	1	Контрольная сумма имени файла DOS
0x0E	12	Символы имени (шесть UCS-2 символов )
0x1A	2	Первый кластер (всегда 0x0000 )
0x1C	4	Символы имени (два UCS-2 символа )

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

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

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

Порядковый номер	скрывать Вводные данные
0x03	"me.ext"
0x02	"Я длинная филена"
0x01	"Файл с версией"
???	Обычная запись 8.3

Контрольная сумма также позволяет проверить, соответствует ли длинное имя файла имени 8.3; такое несоответствие могло произойти, если файл был удален и заново создан с помощью DOS в той же позиции каталога. Контрольная сумма рассчитывается по приведенному ниже алгоритму. (pFCBName — это указатель на имя, которое появляется в обычной записи каталога, т. е. первые восемь символов — это имя файла, а последние три — расширение. Точка является неявной. Любой неиспользуемый пробел в имени файла дополняется пробелами. (ASCII 0x20 ). Например, «Readme.txt» будет « 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;
}

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

См. также

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

Внешние ссылки

• ECMA-107 Том и файловая структура дисковых картриджей для обмена информацией , идентичные ISO/IEC 9293.
• Спецификация файловой системы FAT32, инициатива Microsoft Extensible Firmware Initiative, FAT: общий обзор формата на диске
• Понимание файловых систем FAT32 (поясняется для разработчиков встроенного ПО)
• Понимание FAT, включая много информации о LFN.
• Подробное объяснение загрузочного сектора FAT : статья 140418 базы знаний Microsoft.
• Описание файловой системы FAT32 : статья 154997 базы знаний Microsoft.
• Реализация файловой системы FAT12/FAT16/FAT32 для *nix : включает библиотеки libfat и usefat, драйвер файловой системы FUSE.
• MS-DOS: ограничения каталогов и подкаталогов : статья 39927 базы знаний Microsoft
• Обзор файловых систем FAT, HPFS и NTFS : статья 100108 базы знаний Microsoft
• Ограничения на объем и размер файлов файловых систем FAT : Microsoft Technet, копия сделана Internet Archive Wayback Machine
• Microsoft TechNet: Краткая и неполная история FAT32 Рэймонда Чена
• Средство форматирования FAT32, заархивировано 21 июля 2009 г. на Wayback Machine : позволяет форматировать тома размером более 32 ГБ с помощью FAT32 под Windows 2000 , Windows XP и Windows Vista.
• Fdisk не распознает полный размер жестких дисков объемом более 64 ГБ : статья 263044 базы знаний Microsoft, копия сделана Internet Archive Wayback Machine . Объясняет невозможность работы с очень большими томами под Windows 95/98.
• Microsoft Windows XP: файловая система FAT32 . сделанная Internet Archive Wayback Machine , которая больше не доступна на веб-сайте Microsoft. Копия статьи с кратким описанием ограничений FAT32,
• Визуальное расположение диска FAT16