Проектирование файловой системы FAT
 | В этой статье есть несколько проблем. Пожалуйста, помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти шаблонные сообщения )
|
| Разработчик(и) | Microsoft , SCP , IBM , Compaq , Digital Research , Novell , Caldera |
|---|---|
| Полное имя | Таблица размещения файлов: FAT12 (12-битная версия), FAT16 (16-битные версии), FAT32 (32-битная версия с использованием 28 бит), exFAT (64-битные версии) |
| Introduced | 1977 (Standalone Disk BASIC-80) FAT12: August 1980 (SCP QDOS) FAT16: August 1984 (IBM PC DOS 3.0) FAT16B: November 1987 (Compaq MS-DOS 3.31) FAT32: August 1996 (Windows 95 OSR2) exFAT: November 2006 (Windows Embedded CE 6.0) |
| Partition IDs | MBR/EBR: FAT12: 0x01 e.a.FAT16: 0x040x060x0E e.a.FAT32: 0x0B0x0C e.a.exFAT: 0x07 e.a.BDP: EBD0A0A2-B9E5-443387C0-68B6B72699C7 |
| Structures | |
| Directory contents | Table |
| File allocation | Linked list |
| Bad blocks | Cluster tagging |
| Limits | |
| Max volume size | FAT12: 32 MB (256 MB for 64 KB clusters) FAT16: 2 GB (4 GB for 64 KB clusters) FAT32: 2 TB (16 TB for 4 KB sectors) |
| Max file size | 4,294,967,295 bytes (4 GB - 1) with FAT16B and FAT32[1] |
| Max no. of files | FAT12: 4,068 for 8 KB clusters FAT16: 65,460 for 32 KB clusters FAT32: 268,173,300 for 32 KB clusters |
| Max filename length | 8.3 filename, or 255 UCS-2 characters when using LFN |
| Features | |
| Dates recorded | Modified date/time, creation date/time (DOS 7.0 and higher only), access date (only available with ACCDATE enabled),[2] deletion date/time (only with DELWATCH 2) |
| Date range | 1980-01-01 to 2099-12-31 (2107-12-31) |
| Date resolution | 2 seconds for last modified time, 10 ms for creation time, 1 day for access date, 2 seconds for deletion time |
| Forks | Not natively |
| Attributes | Read-only, Hidden, System, Volume, Directory, Archive |
| File system permissions | FAT12/FAT16: File, directory and volume access rights for Read, Write, Execute, Delete only with DR-DOS, PalmDOS, Novell DOS, OpenDOS, FlexOS, 4680 OS, 4690 OS, Concurrent DOS, Multiuser DOS, System Manager, REAL/32 (Execute right only with FlexOS, 4680 OS, 4690 OS; individual file / directory passwords not with FlexOS, 4680 OS, 4690 OS; World/Group/Owner permission classes only with multiuser security loaded) FAT32: Partial, only with DR-DOS, REAL/32 and 4690 OS |
| Transparent compression | FAT12/FAT16: Per-volume, SuperStor, Stacker, DoubleSpace, DriveSpace FAT32: No |
| Transparent encryption | FAT12/FAT16: Per-volume only with DR-DOS FAT32: No |
Файловая система FAT — это файловая система, используемая в MS-DOS и операционных системах семейства Windows 9x . [ 3 ] Она по-прежнему используется на мобильных устройствах и встроенных системах и, таким образом, является хорошо подходящей файловой системой для обмена данными между компьютерами и устройствами практически любого типа и возраста с 1981 года по настоящее время.
Структура
[ редактировать ]Файловая система FAT состоит из четырех областей:
| Region | Size in sectors | Contents | Notes |
|---|---|---|---|
| Reserved sectors | (number of reserved sectors) | Boot Sector | The first reserved sector (logical sector 0) is the Boot Sector (also called Volume Boot Record or simply VBR). It includes an area called the BIOS Parameter Block (BPB) which contains some basic file system information, in particular its type and pointers to the location of the other sections, and usually contains the operating system's boot loader code.
Important information from the Boot Sector is accessible through an operating system structure called the Drive Parameter Block (DPB) in DOS and OS/2. The total count of reserved sectors is indicated by a field inside the Boot Sector, and is usually 32 on FAT32 file systems.[4] For FAT32 file systems, the reserved sectors include a File System Information Sector at logical sector 1 and a Backup Boot Sector at logical sector 6. While many other vendors have continued to utilize a single-sector setup (logical sector 0 only) for the bootstrap loader, Microsoft's boot sector code has grown to span over logical sectors 0 and 2 since the introduction of FAT32, with logical sector 0 depending on sub-routines in logical sector 2. The Backup Boot Sector area consists of three logical sectors 6, 7, and 8 as well. In some cases, Microsoft also uses sector 12 of the reserved sectors area for an extended boot loader. |
| FS Information Sector (FAT32 only) | |||
| More reserved sectors (optional) | |||
| FAT Region | (number of FATs) * (sectors per FAT) | File Allocation Table #1 | This typically contains two copies of the File Allocation Table for the sake of redundancy checking, although rarely used, even by disk repair utilities. These are maps of the Data Region, indicating which clusters are used by files and directories. In FAT12 and FAT16 they immediately follow the reserved sectors. Typically the extra copies are kept in tight synchronization on writes, and on reads they are only used when errors occur in the first FAT. The first two clusters (cluster 0 and 1) in the map contain special values. |
| File Allocation Table #2 ... (optional) | |||
| Root Directory Region | (number of root entries * 32) / (bytes per sector) | Root Directory (FAT12 and FAT16 only) | This is a Directory Table that stores information about the files and directories located in the root directory. It is only used with FAT12 and FAT16, and imposes on the root directory a fixed maximum size which is pre-allocated at creation of this volume. FAT32 stores the root directory in the Data Region, along with files and other directories, allowing it to grow without such a constraint. Thus, for FAT32, the Data Region starts here. |
| Data Region | (number of clusters) * (sectors per cluster) | Data Region (for files and directories) ... (to end of partition or disk) | This is where the actual file and directory data is stored and takes up most of the partition. FAT32 typically commences the Root Directory Table in cluster number 2: the first cluster of the Data Region. |
FAT uses little-endian format for all entries in the header (except for, where explicitly mentioned, some entries on Atari ST boot sectors) and the FAT(s).[5] It is possible to allocate more FAT sectors than necessary for the number of clusters. The end of the last sector of each FAT copy can be unused if there are no corresponding clusters. The total number of sectors (as noted in the boot record) can be larger than the number of sectors used by data (clusters × sectors per cluster), FATs (number of FATs × sectors per FAT), the root directory (n/a for FAT32), and hidden sectors including the boot sector: this would result in unused sectors at the end of the volume. If a partition contains more sectors than the total number of sectors occupied by the file system it would also result in unused sectors, at the end of the partition, after the volume.
Reserved sectors area
[edit]Boot Sector
[edit]On non-partitioned storage devices, such as floppy disks, the Boot Sector (VBR) is the first sector (logical sector 0 with physical CHS address 0/0/1 or LBA address 0). For partitioned storage devices such as hard disks, the Boot Sector is the first sector of a partition, as specified in the partition table of the device.
BIOS Parameter Block
[edit]
DOS 3.0 BPB:
The following extensions were documented since DOS 3.0, however, they were already supported by some issues of DOS 2.11.[28] MS-DOS 3.10 still supported the DOS 2.0 format, but could use the DOS 3.0 format as well.
| Sector offset | BPB offset | Length (bytes) | Contents |
|---|
DOS 3.2 BPB:
Officially, MS-DOS 3.20 still used the DOS 3.0 format, but SYS and FORMAT were adapted to support a 6 bytes longer format already (of which not all entries were used).
| Sector offset | BPB offset | Length (bytes) | Contents |
|---|---|---|---|
| 0x00B | 0x00 | 19 | DOS 3.0 BPB |
| 0x01E | 0x13 | 2 | Total logical sectors including hidden sectors. This DOS 3.2 entry is incompatible with a similar entry at offset 0x020 in BPBs since DOS 3.31.
It must not be used if the logical sectors entry at offset 0x013 is zero. |
DOS 3.31 BPB:
Officially introduced with DOS 3.31 and not used by DOS 3.2, some DOS 3.2 utilities were designed to be aware of this new format already. Official documentation recommends to trust these values only if the logical sectors entry at offset 0x013 is zero.
| Sector offset | BPB offset | Length (bytes) | Contents |
|---|
A simple formula translates a volume's given cluster number CN to a logical sector number LSN:[24][25][26]
- Determine (once)
SSA=RSC+FN×SF+ceil((32×RDE)/SS), where the reserved sector countRSCis stored at offset 0x00E, the number of FATsFNat offset 0x010, the sectors per FATSFat offset 0x016 (FAT12/FAT16) or 0x024 (FAT32), the root directory entriesRDEat offset 0x011, the sector sizeSSat offset 0x00B, andceil(x)rounds up to a whole number. - Determine
LSN=SSA+(CN−2)×SC, where the sectors per clusterSCare stored at offset 0x00D.
On unpartitioned media the volume's number of hidden sectors is zero and therefore LSN and LBA addresses become the same for as long as a volume's logical sector size is identical to the underlying medium's physical sector size. Under these conditions, it is also simple to translate between CHS addresses and LSNs as well:
LSN=SPT×(HN+(NOS×TN))+SN−1, where the sectors per track SPT are stored at offset 0x018, and the number of sides NOS at offset 0x01A. Track number TN, head number HN, and sector number SN correspond to Cylinder-head-sector: the formula gives the known CHS to LBA translation.
Extended BIOS Parameter Block
[edit]Further structure used by FAT12 and FAT16 since OS/2 1.0 and DOS 4.0, also known as Extended BIOS Parameter Block (EBPB) (bytes below sector offset 0x024 are the same as for the DOS 3.31 BPB):
| Sector offset | EBPB offset | Length (bytes) | Contents |
|---|
FAT32 Extended BIOS Parameter Block
[edit]In essence FAT32 inserts 28 bytes into the EBPB, followed by the remaining 26 (or sometimes only 7) EBPB bytes as shown above for FAT12 and FAT16. Microsoft and IBM operating systems determine the type of FAT file system used on a volume solely by the number of clusters, not by the used BPB format or the indicated file system type, that is, it is technically possible to use a "FAT32 EBPB" also for FAT12 and FAT16 volumes as well as a DOS 4.0 EBPB for small FAT32 volumes. Since such volumes were found to be created by Windows operating systems under some odd conditions,[nb 6] operating systems should be prepared to cope with these hybrid forms.
| Sector offset | FAT32 EBPB offset | Length (bytes) | Contents |
|---|
Exceptions
[edit]Versions of DOS before 3.2 totally or partially relied on the media descriptor byte in the BPB or the FAT ID byte in cluster 0 of the first FAT in order to determine FAT12 diskette formats even if a BPB is present. Depending on the FAT ID found and the drive type detected they default to use one of the following BPB prototypes instead of using the values actually stored in the BPB.[nb 1]
Originally, the FAT ID was meant to be a bit flag with all bits set except for bit 2 cleared to indicate an 80 track (vs. 40 track) format, bit 1 cleared to indicate a 9 sector (vs. 8 sector) format, and bit 0 cleared to indicate a single-sided (vs. double-sided) format,[7] but this scheme was not followed by all OEMs and became obsolete with the introduction of hard disks and high-density formats. Also, the various 8-inch formats supported by 86-DOS and MS-DOS do not fit this scheme.
| FAT ID (compare with media ID at BPB offset 0x0A)[22][23] | 0xFF | 0xFE | 0xFD | 0xFC | 0xFB | 0xFA | 0xF9 | 0xF8 | 0xF0 | 0xED | 0xE5 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Microsoft recommends to distinguish between the two 8-inch formats for FAT ID 0xFE by trying to read of a single-density address mark. If this results in an error, the medium must be double-density.[23]
The table does not list a number of incompatible 8-inch and 5.25-inch FAT12 floppy formats supported by 86-DOS, which differ either in the size of the directory entries (16 bytes vs. 32 bytes) or in the extent of the reserved sectors area (several whole tracks vs. one logical sector only).
The implementation of a single-sided 315 KB FAT12 format used in MS-DOS for the Apricot PC and F1e[34] had a different boot sector layout, to accommodate that computer's non-IBM compatible BIOS. The jump instruction and OEM name were omitted, and the MS-DOS BPB parameters (offsets 0x00B-0x017 in the standard boot sector) were located at offset 0x050. The Portable, F1, PC duo and Xi FD supported a non-standard double-sided 720 KB FAT12 format instead.[34] The differences in the boot sector layout and media IDs made these formats incompatible with many other operating systems. The geometry parameters for these formats are:
- 315 KB: Bytes per logical sector: 512 bytes, logical sectors per cluster: 1, reserved logical sectors: 1, number of FATs: 2, root directory entries: 128, total logical sectors: 630, FAT ID: 0xFC, logical sectors per FAT: 2, physical sectors per track: 9, number of heads: 1.[34][35]
- 720 KB: Bytes per logical sector: 512 bytes, logical sectors per cluster: 2, reserved logical sectors: 1, number of FATs: 2, root directory entries: 176, total logical sectors: 1440, FAT ID: 0xFE, logical sectors per FAT: 3, physical sectors per track: 9, number of heads: 2.[34]
Later versions of Apricot MS-DOS gained the ability to read and write disks with the standard boot sector in addition to those with the Apricot one. These formats were also supported by DOS Plus 2.1e/g for the Apricot ACT series.
The DOS Plus adaptation for the BBC Master 512 supported two FAT12 formats on 80-track, double-sided, double-density 5.25" drives, which did not use conventional boot sectors at all. 800 KB data disks omitted a boot sector and began with a single copy of the FAT.[35] The first byte of the relocated FAT in logical sector 0 was used to determine the disk's capacity. 640 KB boot disks began with a miniature ADFS file system containing the boot loader, followed by a single FAT.[35][36] Also, the 640 KB format differed by using physical CHS sector numbers starting with 0 (not 1, as common) and incrementing sectors in the order sector-track-head (not sector-head-track, as common).[36] The FAT started at the beginning of the next track. These differences make these formats unrecognizable by other operating systems. The geometry parameters for these formats are:
- 800 KB: Bytes per logical sector: 1024 bytes, logical sectors per cluster: 1, reserved logical sectors: 0, number of FATs: 1, root directory entries: 192, total logical sectors: 800, FAT ID: 0xFD, logical sectors per FAT: 2, physical sectors per track: 5, number of heads: 2.[35][36]
- 640 KB: Bytes per logical sector: 256 bytes, logical sectors per cluster: 8, reserved logical sectors: 16, number of FATs: 1, root directory entries: 112, total logical sectors: 2560, FAT ID: 0xFF, logical sectors per FAT: 2, physical sectors per track: 16, number of heads: 2.[35][36]
DOS Plus for the Master 512 could also access standard PC disks formatted to 180 KB or 360 KB, using the first byte of the FAT in logical sector 1 to determine the capacity.
The DEC Rainbow 100 (all variations) supported one FAT12 format on 80-track, single-sided, quad-density 5.25" drives. The first two tracks were reserved for the boot loader, but didn't contain an MBR nor a BPB (MS-DOS used a static in-memory BPB instead). The boot sector (track 0, side 0, sector 1) was Z80 code beginning with DI 0xF3. The 8088 bootstrap was loaded by the Z80. Track 1, side 0, sector 2 starts with the Media/FAT ID byte 0xFA. Unformatted disks use 0xE5 instead. The file system starts on track 2, side 0, sector 1. There are 2 copies of the FAT and 96 entries in the root directory. In addition, there is a physical to logical track mapping to effect a 2:1 sector interleaving. The disks were formatted with the physical sectors in order numbered 1 to 10 on each track after the reserved tracks, but the logical sectors from 1 to 10 were stored in physical sectors 1, 6, 2, 7, 3, 8, 4, 9, 5, 10.[37]
FS Information Sector
[edit]The "FS Information Sector" was introduced in FAT32[38] for speeding up access times of certain operations (in particular, getting the amount of free space). It is located at a logical sector number specified in the FAT32 EBPB boot record at position 0x030 (usually logical sector 1, immediately after the boot record itself).
| Byte offset | Length (bytes) | Contents |
|---|---|---|
| 0x000 | 4 | FS information sector signature (0x52 0x52 0x61 0x41 = "RRaA")
For as long as the FS Information Sector is located in logical sector 1, the location, where the FAT typically started in FAT12 and FAT16 file systems (with only one reserved sectors), the presence of this signature ensures that early versions of DOS will never attempt to mount a FAT32 volume, as they expect the values in cluster 0 and cluster 1 to follow certain bit patterns, which are not met by this signature. |
| 0x004 | 480 | Reserved (byte values should be set to 0x00 during format, but not be relied upon and never changed later on) |
| 0x1E4 | 4 | FS information sector signature (0x72 0x72 0x41 0x61 = "rrAa")
|
| 0x1E8 | 4 | Last known number of free data clusters on the volume, or 0xFFFFFFFF if unknown. Should be set to 0xFFFFFFFF during format and updated by the operating system later on. Must not be absolutely relied upon to be correct in all scenarios. Before using this value, the operating system should sanity check this value to be less than or equal to the volume's count of clusters. |
| 0x1EC | 4 | Number of the most recently known to be allocated data cluster. Should be set to 0xFFFFFFFF during format and updated by the operating system later on. With 0xFFFFFFFF the system should start at cluster 0x00000002. Must not be absolutely relied upon to be correct in all scenarios. Before using this value, the operating system should sanity check this value to be a valid cluster number on the volume. |
| 0x1F0 | 12 | Reserved (byte values should be set to 0x00 during format, but not be relied upon and never changed later on) |
| 0x1FC | 4 | FS information sector signature (0x00 0x00 0x55 0xAA)[4][nb 2] (All four bytes should match before the contents of this sector should be assumed to be in valid format.) |
The sector's data may be outdated and not reflect the current media contents, because not all operating systems update or use this sector, and even if they do, the contents is not valid when the medium has been ejected without properly unmounting the volume or after a power-failure. Therefore, operating systems should first inspect a volume's optional shutdown status bitflags residing in the FAT entry of cluster 1 or the FAT32 EBPB at offset 0x041 and ignore the data stored in the FS information sector, if these bitflags indicate that the volume was not properly unmounted before. This does not cause any problems other than a possible speed penalty for the first free space query or data cluster allocation; see fragmentation.
If this sector is present on a FAT32 volume, the minimum allowed logical sector size is 512 bytes, whereas otherwise it would be 128 bytes. Some FAT32 implementations support a slight variation of Microsoft's specification by making the FS information sector optional by specifying a value of 0xFFFF[19] (or 0x0000) in the entry at offset 0x030.
FAT region
[edit]File Allocation Table
[edit]
Cluster map
[edit] | This article may overuse or misuse color, making it hard to understand for color-blind users. |
A volume's data area is divided into identically sized clusters—small blocks of contiguous space. Cluster sizes vary depending on the type of FAT file system being used and the size of the drive; typical cluster sizes range from 2 to 32 KiB.[39]
Each file may occupy one or more clusters depending on its size. Thus, a file is represented by a chain of clusters (referred to as a singly linked list). These clusters are not necessarily stored adjacent to one another on the disk's surface but are often instead fragmented throughout the Data Region.
Each version of the FAT file system uses a different size for FAT entries. Smaller numbers result in a smaller FAT, but waste space in large partitions by needing to allocate in large clusters.
The FAT12 file system uses 12 bits per FAT entry, thus two entries span 3 bytes. It is consistently little-endian: if those three bytes are considered as one little-endian 24-bit number, the 12 least significant bits represent the first entry (e.g. cluster 0) and the 12 most significant bits the second (e.g. cluster 1). In other words, while the low eight bits of the first cluster in the row are stored in the first byte, the top four bits are stored in the low nibble of the second byte, whereas the low four bits of the subsequent cluster in the row are stored in the high nibble of the second byte and its higher eight bits in the third byte.
| Offset | +0 | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +9 | +A | +B | +C | +D | +E | +F |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| +0000 | F0 | FF | FF | 03 | 40 | 00 | 05 | 60 | 00 | 07 | 80 | 00 | FF | AF | 00 | 14 |
| +0010 | C0 | 00 | 0D | E0 | 00 | 0F | 00 | 01 | 11 | F0 | FF | 00 | F0 | FF | 15 | 60 |
| +0020 | 01 | 19 | 70 | FF | F7 | AF | 01 | FF | 0F | 00 | 00 | 70 | FF | 00 | 00 | 00 |
- FAT ID / endianness marker (in reserved cluster #0), with 0xF0 indicating a volume on a non-partitioned superfloppy drive (must be 0xF8 for partitioned disks)
- End of chain indicator / maintenance flags (in reserved cluster #1)
- Second chain (7 clusters) for a non-fragmented file (here: #2, #3, #4, #5, #6, #7, #8)
- Third chain (7 clusters) for a fragmented, possibly grown file (here: #9, #A, #14, #15, #16, #19, #1A)
- Fourth chain (7 clusters) for a non-fragmented, possibly truncated file (here: #B, #C, #D, #E, #F, #10, #11)
- Empty clusters (here: #12, #1B, #1C, #1E, #1F)
- Fifth chain (1 cluster) for a sub-directory (here: #13)
- Bad clusters (3 clusters) (here: #17, #18, #1D)
The FAT16 file system uses 16 bits per FAT entry, thus one entry spans two bytes in little-endian byte order:
| Offset | +0 | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +9 | +A | +B | +C | +D | +E | +F |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| +0000 | F0 | FF | FF | FF | 03 | 00 | 04 | 00 | 05 | 00 | 06 | 00 | 07 | 00 | 08 | 00 |
| +0010 | FF | FF | 0A | 00 | 14 | 00 | 0C | 00 | 0D | 00 | 0E | 00 | 0F | 00 | 10 | 00 |
| +0020 | 11 | 00 | FF | FF | 00 | 00 | FF | FF | 15 | 00 | 16 | 00 | 19 | 00 | F7 | FF |
| +0030 | F7 | FF | 1A | 00 | FF | FF | 00 | 00 | 00 | 00 | F7 | FF | 00 | 00 | 00 | 00 |
The FAT32 file system uses 32 bits per FAT entry, thus one entry spans four bytes in little-endian byte order. The four top bits of each entry are reserved for other purposes; they are cleared during formatting and should not be changed otherwise. They must be masked off before interpreting the entry as 28-bit cluster address.
| Offset | +0 | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +9 | +A | +B | +C | +D | +E | +F |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| +0000 | F0 | FF | FF | 0F | FF | FF | FF | 0F | FF | FF | FF | 0F | 04 | 00 | 00 | 00 |
| +0010 | 05 | 00 | 00 | 00 | 06 | 00 | 00 | 00 | 07 | 00 | 00 | 00 | 08 | 00 | 00 | 00 |
| +0020 | FF | FF | FF | 0F | 0A | 00 | 00 | 00 | 14 | 00 | 00 | 00 | 0C | 00 | 00 | 00 |
| +0030 | 0D | 00 | 00 | 00 | 0E | 00 | 00 | 00 | 0F | 00 | 00 | 00 | 10 | 00 | 00 | 00 |
| +0040 | 11 | 00 | 00 | 00 | FF | FF | FF | 0F | 00 | 00 | 00 | 00 | FF | FF | FF | 0F |
| +0050 | 15 | 00 | 00 | 00 | 16 | 00 | 00 | 00 | 19 | 00 | 00 | 00 | F7 | FF | FF | 0F |
| +0060 | F7 | FF | FF | 0F | 1A | 00 | 00 | 00 | FF | FF | FF | 0F | 00 | 00 | 00 | 00 |
| +0070 | 00 | 00 | 00 | 00 | F7 | FF | FF | 0F | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 |
- First chain (1 cluster) for the root directory, pointed to by an entry in the FAT32 BPB (here: #2)
- Second chain (6 clusters) for a non-fragmented file (here: #3, #4, #5, #6, #7, #8)
The File Allocation Table (FAT) is a contiguous number of sectors immediately following the area of reserved sectors. It represents a list of entries that map to each cluster on the volume. Each entry records one of four things:
- the cluster number of the next cluster in a chain
- a special end of cluster-chain (EOC) entry that indicates the end of a chain
- a special entry to mark a bad cluster
- a zero to note that the cluster is unused
For very early versions of DOS to recognize the file system, the system must have been booted from the volume or the volume's FAT must start with the volume's second sector (logical sector 1 with physical CHS address 0/0/2 or LBA address 1), that is, immediately following the boot sector. Operating systems assume this hard-wired location of the FAT in order to find the FAT ID in the FAT's cluster 0 entry on DOS 1.0-1.1 FAT diskettes, where no valid BPB is found.
Special entries
[edit]The first two entries in a FAT store special values:
The first entry (cluster 0 in the FAT) holds the FAT ID since MS-DOS 1.20 and PC DOS 1.1 (allowed values 0xF0-0xFF with 0xF1-0xF7 reserved) in bits 7-0, which is also copied into the BPB of the boot sector, offset 0x015 since DOS 2.0. The remaining 4 bits (if FAT12), 8 bits (if FAT16) or 20 bits (if FAT32, the 4 MSB bits are zero) of this entry are always 1. These values were arranged so that the entry would also function as a "trap-all" end-of-chain marker for all data clusters holding a value of zero. Additionally, for FAT IDs other than 0xFF (and 0x00) it is possible to determine the correct nibble and byte order (to be) used by the file system driver, however, the FAT file system officially uses a little-endian representation only and there are no known implementations of variants using big-endian values instead. 86-DOS 0.42 up to MS-DOS 1.14 used hard-wired drive profiles instead of a FAT ID, but used this byte to distinguish between media formatted with 32-byte or 16-byte directory entries, as they were used prior to 86-DOS 0.42.
The second entry (cluster 1 in the FAT) nominally stores the end-of-cluster-chain marker as used by the formater, but typically always holds 0xFFF / 0xFFFF / 0x0FFFFFFF, that is, with the exception of bits 31-28 on FAT32 volumes these bits are normally always set. Some Microsoft operating systems, however, set these bits if the volume is not the volume holding the running operating system (that is, use 0xFFFFFFFF instead of 0x0FFFFFFF here).[40] (In conjunction with alternative end-of-chain markers the lowest bits 2-0 can become zero for the lowest allowed end-of-chain marker 0xFF8 / 0xFFF8 / 0x?FFFFFF8; bit 3 should be reserved as well given that clusters 0xFF0 / 0xFFF0 / 0x?FFFFFF0 and higher are officially reserved. Some operating systems may not be able to mount some volumes if any of these bits are not set, therefore the default end-of-chain marker should not be changed.) For DOS 1 and 2, the entry was documented as reserved for future use.
Since DOS 7.1 the two most-significant bits of this cluster entry may hold two optional bitflags representing the current volume status on FAT16 and FAT32, but not on FAT12 volumes. These bitflags are not supported by all operating systems, but operating systems supporting this feature would set these bits on shutdown and clear the most significant bit on startup:
If bit 15 (on FAT16) or bit 27 (on FAT32)[41] is not set when mounting the volume, the volume was not properly unmounted before shutdown or ejection and thus is in an unknown and possibly "dirty" state.[27] On FAT32 volumes, the FS Information Sector may hold outdated data and thus should not be used. The operating system would then typically run SCANDISK or CHKDSK on the next startup[nb 9][41] (but not on insertion of removable media) to ensure and possibly reestablish the volume's integrity.
If bit 14 (on FAT16) or bit 26 (on FAT32)[41] is cleared, the operating system has encountered disk I/O errors on startup,[41] a possible indication for bad sectors. Operating systems aware of this extension will interpret this as a recommendation to carry out a surface scan (SCANDISK) on the next boot.[27][41] (A similar set of bitflags exists in the FAT12/FAT16 EBPB at offset 0x1A or the FAT32 EBPB at offset 0x36. While the cluster 1 entry can be accessed by file system drivers once they have mounted the volume, the EBPB entry is available even when the volume is not mounted and thus easier to use by disk block device drivers or partitioning tools.)
If the number of FATs in the BPB is not set to 2, the second cluster entry in the first FAT (cluster 1) may also reflect the status of a TFAT volume for TFAT-aware operating systems. If the cluster 1 entry in that FAT holds the value 0, this may indicate that the second FAT represents the last known valid transaction state and should be copied over the first FAT, whereas the first FAT should be copied over the second FAT if all bits are set.
Some non-standard FAT12/FAT16 implementations utilize the cluster 1 entry to store the starting cluster of a variable-sized root directory (typically 2[33]). This may occur when the number of root directory entries in the BPB holds a value of 0 and no FAT32 EBPB is found (no signature 0x29 or 0x28 at offset 0x042).[20] This extension, however, is not supported by mainstream operating systems,[20] as it conflicts with other possible uses of the cluster 1 entry. Most conflicts can be ruled out if this extension is only allowed for FAT12 with less than 0xFEF and FAT16 volumes with less than 0x3FEF clusters and 2 FATs.
Because these first two FAT entries store special values, there are no data clusters 0 or 1. The first data cluster (after the root directory if FAT12/FAT16) is cluster 2,[33] marking the beginning of the data area.
Cluster values
[edit]FAT entry values:
| FAT12 | FAT16 | FAT32 | Description |
|---|---|---|---|
| 0x000 | 0x0000 | 0x?0000000 | Free Cluster; also used by DOS to refer to the parent directory starting cluster in ".." entries of subdirectories of the root directory on FAT12/FAT16 volumes.[42][6]
Otherwise, if this value occurs in cluster chains (e.g. in directory entries of zero length or deleted files), file system implementations should treat this like an end-of-chain marker.[7] |
| 0x001 | 0x0001 | 0x?0000001 | Reserved for internal purposes; MS-DOS/PC DOS use this cluster value as a temporary non-free cluster indicator while constructing cluster chains during file allocation (only seen on disk if there is a crash or power failure in the middle of this process).[42][6]
If this value occurs in on-disk cluster chains, file system implementations should treat this like an end-of-chain marker. |
| 0x002 - 0xFEF | 0x0002 - 0xFFEF (0x0002 - 0x7FFF) | 0x?0000002 - 0x?FFFFFEF | Used as data clusters; value points to next cluster. MS-DOS/PC DOS accept values up to 0xFEF / 0xFFEF / 0x0FFFFFEF (sometimes more; see below), whereas for Atari GEMDOS only values up to 0x7FFF are allowed on FAT16 volumes. |
| 0xFF0[nb 10] - 0xFF5 (0xFF1 - 0xFF5) | 0xFFF0 - 0xFFF5 | 0x?FFFFFF0 - 0x?FFFFFF5 | Reserved in some contexts,[43] or also used[24][25][26][4][44] as data clusters in some non-standard systems. Volume sizes which would utilize these values as data clusters should be avoided, but if these values occur in existing volumes, the file system must treat them as normal data clusters in cluster-chains (ideally applying additional sanity checks), similar to what MS-DOS, PC DOS and DR-DOS do,[6] and should avoid allocating them for files otherwise.
MS-DOS/PC DOS 3.3 and higher treats a value of 0xFF0[nb 10][6] on FAT12 (but not on FAT16 or FAT32) volumes as additional end-of-chain marker similar to 0xFF8-0xFFF.[6] For compatibility with MS-DOS/PC DOS, file systems should avoid to use data cluster 0xFF0 in cluster chains on FAT12 volumes (that is, treat it as a reserved cluster similar to 0xFF7). (NB. The correspondence of the low byte of the cluster number with the FAT ID and media descriptor values is the reason, why these cluster values are reserved.) |
| 0xFF6 | 0xFFF6 | 0x?FFFFFF6 | Reserved; do not use.[24][25][26][4][21][44] (NB. Corresponds with the default format filler value 0xF6 on IBM compatible machines.) Volumes should not be created which would utilize this value as data cluster, but if this value occurs in existing volumes, the file system must treat it as normal data cluster in cluster-chains (ideally applying additional sanity checks), and should avoid to allocate it for files otherwise.[7] |
| 0xFF7 | 0xFFF7 | 0x?FFFFFF7 | Bad sector in cluster or reserved cluster (since DOS 2.0).
The cutover values for the maximum number of clusters for FAT12 and FAT16 file systems are defined as such that the highest possible data cluster values (0xFF5 and 0xFFF5,[6] respectively) will always be smaller than this value.[6] Therefore, this value cannot normally occur in cluster-chains, but if it does, it may be treated as a normal data cluster, since 0xFF7 could have been a non-standard data cluster on FAT12 volumes before the introduction of the bad cluster marker with DOS 2.0 or the introduction of FAT16 with DOS 3.0,[7] and 0xFFF7 could have been a non-standard data cluster on FAT16 volumes before the introduction of FAT32 with DOS 7.10. Theoretically, 0x0FFFFFF7 can be part of a valid cluster chain on FAT32 volumes, but disk utilities should avoid creating FAT32 volumes, where this condition could occur. The file system should avoid to allocate this cluster for files.[7] Disk utilities must not attempt to restore "lost clusters" holding this value in the FAT, but count them as bad clusters. |
| 0xFF8 - 0xFFF (and optionally 0xFF0;[nb 10] see note) | 0xFFF8 - 0xFFFF | 0x?FFFFFF8 - 0x?FFFFFFF | Last cluster in file (EOC). File system implementations must treat all these values as end-of-chain marker at the same time.[7] Most file system implementations (including 86-DOS, MS-DOS, PC DOS and DR-DOS) use 0xFFF[7] / 0xFFFF[7] / 0x0FFFFFFF as end-of-file marker when allocating files, but versions of Linux before 2.5.40 used 0xFF8 / 0xFFF8 / 0x0FFFFFF8.[45] Versions of mkdosfs (dosfstools up to 3.0.26) continue to use 0x0FFFFFF8 for the root directory on FAT32 volumes, whereas some disk repair and defragment tools utilize other values in the set (e.g., SCANDISK may use 0xFF8 / 0xFFF8 / 0x0FFFFFF8 instead). While in the original 8-bit FAT implementation in Microsoft's Standalone Disk BASIC different end markers (0xC0..0xCD) were used to indicate the number of sectors (0 to 13) used up in the last cluster occupied by a file, different end markers were repurposed under DOS to indicate different types of media,[7] with the currently used end marker indicated in the cluster 1 entry, however, this concept does not seem to have been broadly utilized in practice—and to the extent that in some scenarios volumes may not be recognized by some operating systems, if some of the low-order bits of the value stored in cluster 1 are not set. Also, some faulty file system implementations only accept 0xFFF / 0xFFFF / 0x?FFFFFFF as valid end-of-chain marker.
File system implementations should check cluster values in cluster-chains against the maximum allowed cluster value calculated by the actual size of the volume and treat higher values as if they were end-of-chain markers as well. (The low byte of the cluster number conceptually corresponds with the FAT ID and media descriptor values;[7] see note above for MS-DOS/PC DOS special usage of 0xFF0[nb 10] on FAT12 volumes.[6]) |
FAT32 uses 28 bits for cluster numbers. The remaining 4 bits in the 32-bit FAT entry are usually zero, but are reserved and should be left untouched. A standard conformant FAT32 file system driver or maintenance tool must not rely on the upper 4 bits to be zero and it must strip them off before evaluating the cluster number in order to cope with possible future expansions where these bits may be used for other purposes. They must not be cleared by the file system driver when allocating new clusters, but should be cleared during a reformat.
Root directory region
[edit]The root directory table in FAT12 and FAT16 file systems occupies the special Root Directory Region location.
Data region
[edit]Aside from the root directory table in FAT12 and FAT16 file systems, which occupies the special Root Directory Region location, all directory tables are stored in the data region. The actual number of entries in a directory stored in the data region can grow by adding another cluster to the chain in the FAT.
Directory table
[edit]A directory table is a special type of file that represents a directory (also known as a folder). Since 86-DOS 0.42,[46] each file or (since MS-DOS 1.40 and PC DOS 2.0) subdirectory stored within it is represented by a 32-byte entry in the table. Each entry records the name, extension, attributes (archive, directory, hidden, read-only, system and volume), the address of the first cluster of the file/directory's data, the size of the file/directory, and the date[46] and (since PC DOS 1.1) also the time of last modification. Earlier versions of 86-DOS used 16-byte directory entries only, supporting no files larger than 16 MB and no time of last modification.[46]
Сама файловая система FAT не накладывает никаких ограничений на глубину дерева подкаталогов, пока существуют свободные кластеры для размещения подкаталогов, однако внутренняя структура текущих каталогов (CDS) в MS-DOS/PC DOS ограничивает абсолютный путь к каталогу длиной до 66 символов (включая букву диска, но без учета байтового разделителя NUL), [ 24 ] [ 25 ] [ 26 ] тем самым ограничивая максимальную поддерживаемую глубину подкаталогов до 32, что бы ни произошло раньше. Concurrent DOS, Multiuser DOS и DR DOS версий 3.31–6.0 (вплоть до обновлений 1992–11 гг.) не сохраняют внутри себя абсолютные пути к рабочим каталогам и, следовательно, не отображают это ограничение. [ 47 ] То же самое относится и к Atari GEMDOS, но Atari Desktop не поддерживает более 8 уровней подкаталогов. Большинство приложений, знающих об этом расширении, поддерживают пути длиной не менее 127 байт. FlexOS, 4680 OS и 4690 OS также поддерживают длину до 127 байт, что позволяет уменьшить глубину до 60 уровней. [ 48 ] PalmDOS, DR DOS 6.0 (начиная с BDOS 7.1) и выше, Novell DOS и OpenDOS имеют 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". Операционная система удалит один [ 47 ] (а также две — начиная с DR-DOS 7.02) точки с запятой и ожидающие пароли из имен файлов перед их сохранением на диске. (Командный процессор 4DOS использует точки с запятой для списков включения и требует, чтобы точка с запятой удваивалась для файлов, защищенных паролем, с любыми командами, поддерживающими подстановочные знаки. [ 47 ] )
Символ at ( @) используется для списков файлов многими командами DR-DOS, PalmDOS, Novell DOS, OpenDOS и Multiuser DOS, System Manager и REAL/32, а также 4DOS, и поэтому иногда его может быть сложно использовать в именах файлов. [ 47 ]
В многопользовательском DOS и REAL/32 восклицательный знак (!) не является допустимым символом имени файла, поскольку он используется для разделения нескольких команд в одной командной строке. [ 47 ]
В ОС IBM 4680 и 4690 в именах файлов не допускаются следующие символы:
? * : . ; , [ ] ! + = < > " - / \ |
Кроме того, следующие специальные символы не допускаются в первом, четвертом, пятом и восьмом символе имени файла, поскольку они конфликтуют с командным процессором хоста (HCP) и именами файлов построения таблицы входных последовательностей:
@ # ( ) { } $ &
Имена файлов DOS имеют текущий набор символов OEM : это может иметь неожиданные последствия, если символы, обрабатываемые одним способом для данной кодовой страницы, интерпретируются по-разному для другой кодовой страницы (команда DOS CHCP) в отношении нижнего и верхнего регистра, сортировки или допустимости символа имени файла.
Запись в каталоге
[ редактировать ]До того, как Microsoft добавила поддержку длинных имен файлов и меток времени создания/доступа, байты 0x0C – 0x15 записи каталога использовались другими операционными системами для хранения дополнительных метаданных, в первую очередь операционные системы семейства Digital Research хранили там пароли файлов, права доступа, идентификаторы владельцев и данные об удалении файлов. Хотя новые расширения Microsoft по умолчанию не полностью совместимы с этими расширениями, большинство из них могут сосуществовать в сторонних реализациях FAT (по крайней мере, на томах FAT12 и FAT16).
32-байтовые записи каталога как в корневом каталоге, так и в подкаталогах имеют следующий формат (см. также имя файла 8.3 ):
| Компенсация обмена | Длина (байты) | Содержание |
|---|
Операционные системы FlexOS на базе IBM 4680 OS и IBM 4690 поддерживают уникальные атрибуты распределения, хранящиеся в некоторых битах ранее зарезервированных областей в записях каталога: [ 62 ]
- Локальный: не распространять файл, а хранить только на локальном контроллере. [ номер 14 ]
- Зеркальное отображение файла при обновлении: Распространять файл на сервер только при обновлении файла.
- Зеркальное отображение файла при закрытии: Распространять файл на сервер только после закрытия файла.
- Составной файл при обновлении: Распространение файла на все контроллеры при обновлении файла.
- Составной файл при закрытии: Распространение файла на все контроллеры при закрытии файла. [ 63 ]
Некоторые несовместимые расширения, обнаруженные в некоторых операционных системах, включают:
| Компенсация обмена | Длина (байты) | Система | Описание |
|---|
Ограничения по размеру
[ редактировать ]Варианты файловых систем FAT12, FAT16, FAT16B и FAT32 имеют четкие ограничения, основанные на количестве кластеров и количестве секторов в кластере (1, 2, 4, ..., 128). Для типичного значения 512 байт на сектор:
Требования FAT12: 3 сектора в каждой копии FAT на каждые 1024 кластера.
Требования FAT16: 1 сектор в каждой копии FAT на каждые 256 кластеров.
Требования FAT32: 1 сектор в каждой копии FAT на каждые 128 кластеров.
Диапазон FAT12: от 1 до 4084 кластеров: от 1 до 12 секторов на копию FAT
Диапазон FAT16: от 4085 до 65524 кластеров: от 16 до 256 секторов на копию FAT
Диапазон FAT32: от 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 не используется. [ 33 ] Аналогично 65524+3 0xFFF7 для FAT16 и 4084+3 0xFF7 для FAT12. Количество секторов в кластере — это степень 2, умещающаяся в один байт, наименьшее значение — 1 ( 0x01 ), самое большое значение — 128 ( 0x80 ). Линии в квадратных скобках обозначают необычный размер кластера 128, а для FAT32 — больший, чем необходимо, размер кластера 32 или 64. [ 64 ]
Поскольку каждая запись FAT32 занимает 32 бита (4 байта), максимальное количество кластеров (268435444) требует 2097152 секторов FAT для размера сектора 512 байт. 2097152 это 0x200000 , и для хранения этого значения требуется более двух байтов. Таким образом, FAT32 ввела новое 32-битное значение в загрузочном секторе FAT32 сразу после 32-битного значения общего количества секторов, представленного в варианте FAT16B.
Расширения загрузочных записей, представленные в DOS 4.0, начинаются с магической цифры 40 ( 0x28 ) или 41 ( 0x29 ). Обычно драйверы FAT смотрят только на количество кластеров, чтобы отличить FAT12, FAT16 и FAT32: читаемые человеком строки, идентифицирующие вариант FAT в загрузочной записи, игнорируются, поскольку они существуют только для носителей, отформатированных в DOS 4.0 или более поздней версии.
Определить количество записей каталога на кластер несложно. Каждая запись занимает 32 байта; в результате получается 16 записей на сектор при размере сектора 512 байт. ДОС 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. [ 24 ] и ИСО/МЭК 9293 [ 25 ] [ 26 ] укажите максимальное число кластеров MAX определяется по формуле MAX=1+trunc((TS-SSA)/SC)и зарезервируйте номера кластеров MAX+1 до 4086 ( 0xFF6 , FAT12) и более поздних версий 65526 ( 0xFFF6 , FAT16) для будущей стандартизации.
Спецификация Microsoft EFI FAT32 [ 4 ] утверждает, что любая файловая система FAT с числом кластеров менее 4085 — это FAT12, в противном случае любая файловая система FAT с числом кластеров менее 65 525 — это FAT16, а в противном случае — FAT32. Запись для кластера 0 в начале FAT должна быть идентична байту дескриптора носителя, найденному в BPB, тогда как запись для кластера 1 отражает значение конца цепочки, используемое форматировщиком для цепочек кластеров ( 0xFFF , 0xFFFF или 0x0FFFFFF ). Записи для номеров кластеров 0 и 1 заканчиваются на границе байта даже для FAT12, например: 0xF9FFFF для дескриптора мультимедиа 0xF9 .
Первый кластер данных равен 2, [ 33 ] и, следовательно, последний кластер MAX получает номер MAX+1. В результате получаются номера кластеров данных 2...4085 ( 0xFF5 ) для FAT12, 2...65525 ( 0xFFF5 ) для FAT16 и 2...268435445 ( 0x0FFFFFF5 ) для FAT32.
Таким образом, единственными доступными значениями, зарезервированными для будущей стандартизации, являются 0xFF6 (FAT12) и 0xFFF6 (FAT16). Как отмечено ниже, «менее 4085» также используется для реализаций Linux. [ 44 ] или, как Microsoft FAT: это указано в спецификации [ 4 ]
...когда говорится <, это не означает <=. Также обратите внимание, что цифры верны. Первое число для FAT12 — 4085; второе число для FAT16 — 65525. Эти цифры и знаки «<» не являются ошибочными».
Фрагментация
[ редактировать ]
Файловая система FAT не содержит встроенных механизмов, предотвращающих разброс вновь записанных файлов по разделу. [ 65 ] На томах, где файлы часто создаются и удаляются или их длина часто меняется, носитель со временем становится все более фрагментированным.
Хотя конструкция файловой системы FAT не приводит к каким-либо организационным накладным расходам в дисковых структурах или уменьшению объема свободного места хранения при увеличении степени фрагментации , как это происходит при внешней фрагментации , время, необходимое для чтения и записи фрагментированных файлов, будет увеличиваться по мере увеличения количества фрагментированных файлов. операционная система должна будет следовать цепочкам кластеров в FAT (при этом части должны быть сначала загружены в память, особенно на больших объемах) и читать соответствующие данные, физически разбросанные по всей среде, что снижает вероятность использования драйвера блочного устройства низкого уровня. для выполнения многосекторного дискового ввода-вывода или инициации более крупных передач DMA, тем самым эффективно увеличивая накладные расходы протокола ввода-вывода, а также время движения руки и времени стабилизации головки внутри дисковода. Кроме того, файловые операции станут медленнее с ростом фрагментации, поскольку операционной системе потребуется все больше времени для поиска файлов или свободных кластеров.
Другие файловые системы, например, HPFS или exFAT , используют растровые изображения свободного пространства , которые указывают используемые и доступные кластеры, которые затем можно быстро просмотреть, чтобы найти свободные смежные области. Другое решение — объединение всех свободных кластеров в один или несколько списков (как это сделано в файловых системах Unix ). Вместо этого FAT необходимо сканировать как массив для поиска свободных кластеров, что может привести к снижению производительности при работе с большими дисками.
Фактически поиск файлов в больших подкаталогах или вычисление свободного дискового пространства на томах FAT — одна из наиболее ресурсоемких операций, поскольку требует линейного чтения таблиц каталогов или даже всей FAT. Поскольку общее количество кластеров и размер их записей в FAT все еще были небольшими на томах FAT12 и FAT16, в большинстве случаев с этим можно было мириться на томах FAT12 и FAT16, учитывая, что введение более сложных дисковых структур потребовало бы большего. также увеличили сложность и объем памяти операционных систем реального режима с их минимальными общими требованиями к памяти 128 КБ или меньше (например, в DOS), для которых FAT изначально была разработана и оптимизирована.
С появлением FAT32 длительное время поиска и сканирования стало более очевидным, особенно на очень больших томах. Возможным оправданием, предложенным Рэймондом Ченом из Microsoft для ограничения максимального размера разделов FAT32, создаваемых в Windows, было время, необходимое для выполнения " DIR» операция, которая всегда отображает свободное место на диске в последней строке. [ 66 ] Отображение этой строки занимало все больше и больше времени по мере увеличения количества кластеров. Поэтому в FAT32 появился специальный сектор информации о файловой системе, в котором ранее вычисленный объем свободного пространства сохраняется в течение циклов включения и выключения, так что счетчик свободного пространства необходимо пересчитывать только тогда, когда съемный носитель в формате FAT32 извлекается без предварительного его размонтирования или если система выключается без надлежащего завершения работы операционной системы. Эта проблема чаще всего заметна на компьютерах до ATX -типа, в простых системах DOS и некоторых потребительских продуктах с батарейным питанием.
Из-за огромных размеров кластера (16 КБ, 32 КБ, 64 КБ), вызванных большими разделами FAT, внутренняя фрагментация в виде потери дискового пространства из-за нехватки файлов из-за перевеса кластера (поскольку файлы редко кратны размеру кластера) становится проблемой. тоже проблема, особенно когда мелких файлов очень много.
Различные оптимизации и настройки реализации драйверов файловой системы FAT, драйверов блочных устройств и дисковых инструментов были разработаны для преодоления большинства узких мест производительности в конструкции файловой системы без необходимости изменения структуры структур на диске. [ 67 ] [ 68 ] Их можно разделить на онлайновые и автономные методы, и они работают, пытаясь в первую очередь избежать фрагментации файловой системы, развертывая методы, позволяющие лучше справляться с существующей фрагментацией, а также переупорядочивая и оптимизируя структуры на диске. При наличии оптимизации производительность томов FAT часто может достигать производительности более сложных файловых систем в практических сценариях, сохраняя в то же время преимущество доступности даже на очень маленьких или старых системах.
DOS 3.0 и выше не будет немедленно повторно использовать дисковое пространство удаленных файлов для новых выделений, а вместо этого будет искать ранее неиспользованное пространство, прежде чем начать использовать также дисковое пространство ранее удаленных файлов. Это не только помогает сохранять целостность удаленных файлов как можно дольше, но также ускоряет выделение файлов и позволяет избежать фрагментации, поскольку никогда ранее выделенное дисковое пространство не было всегда нефрагментировано. DOS достигает этого, сохраняя в памяти указатель на последний выделенный кластер на каждом смонтированном томе и начинает поиск свободного места от этого места вверх, а не в начале FAT, как это все еще делалось в DOS 2.x. [ 13 ] Если достигнут конец FAT, поиск продолжится в начале FAT до тех пор, пока либо не будет найдено свободное пространство, либо пока исходная позиция не будет достигнута снова без обнаружения свободного места. [ 13 ] Эти указатели инициализируются так, чтобы указывать на начало файлов FAT после загрузки. [ 13 ] но на томах FAT32 DOS 7.1 и выше попытается получить последнюю позицию из информационного сектора FS . Однако этот механизм терпит неудачу, если приложение часто удаляет и воссоздает временные файлы, поскольку в этом случае операционная система будет пытаться сохранить целостность пустых данных, что в конечном итоге приведет к еще большей фрагментации. [ 13 ] В некоторых версиях DOS во избежание этой проблемы можно использовать специальную функцию API для создания временных файлов.
Кроме того, записи каталога удаленных файлов будут отмечены 0xE5 начиная с DOS 3.0. [ 42 ] DOS 5.0 и выше начнут повторно использовать эти записи только тогда, когда ранее неиспользуемые записи каталога будут израсходованы в таблице, и в противном случае системе придется расширить таблицу самостоятельно. [ 6 ]
Начиная с DOS 3.3, операционная система предоставляет средства для повышения производительности файловых операций с FASTOPEN отслеживая положение недавно открытых файлов или каталогов в различных формах списков (MS-DOS/PC DOS) или хеш-таблиц (DR-DOS), что может значительно сократить время поиска и открытия файлов. До DOS 5.0 необходимо проявлять особую осторожность при использовании таких механизмов вместе с программным обеспечением для дефрагментации диска в обход файловой системы или драйверов диска.
Windows NT заранее выделяет дисковое пространство для файлов в FAT, выбирая большие смежные области, но в случае сбоя добавляемые файлы будут выглядеть больше, чем они когда-либо были записаны, с большим количеством случайных данных в конце.
Другие механизмы высокого уровня могут считывать и обрабатывать более крупные части или полную FAT при запуске или по требованию, когда это необходимо, и динамически создавать в памяти древовидные представления файловых структур тома, отличные от структур на диске. [ 67 ] [ 68 ] На томах с большим количеством свободных кластеров это может занимать даже меньше памяти, чем образ самой FAT. В частности, на сильно фрагментированных или заполненных томах поиск становится намного быстрее, чем при линейном сканировании фактической FAT, даже если образ FAT будет храниться в памяти. Кроме того, работая на логически высоком уровне файлов и цепочек кластеров, а не на уровне секторов или дорожек, становится возможным в первую очередь избежать некоторой степени фрагментации файлов или выполнить локальную дефрагментацию файлов и переупорядочение записей каталога на основе их имена или шаблоны доступа в фоновом режиме.
Некоторые из предполагаемых проблем с фрагментацией файловых систем FAT также являются результатом ограничений производительности базовых драйверов блочных устройств , которые становятся тем более заметными, чем меньше памяти доступно для буферизации секторов и блокировки/деблокирования дорожек:
В то время как однозадачная DOS имела возможности для многосекторного чтения и блокировки/разблокировки дорожек, операционная система и традиционная архитектура жесткого диска ПК ( только один выполняющийся запрос ввода/вывода одновременно и отсутствие передачи DMA ) изначально не содержали механизмов что могло бы облегчить фрагментацию за счет асинхронной предварительной выборки следующих данных, пока приложение обрабатывало предыдущие фрагменты. Такие возможности стали доступны позже. Более поздние версии DOS также обеспечивали встроенную поддержку буферизации секторов с упреждающим просмотром и поставлялись с динамически загружаемыми программами дискового кэширования, работающими на уровне физических или логических секторов, часто использующими память EMS или XMS , а иногда предоставляющими стратегии адаптивного кэширования или даже работающими в защищенном режиме через DPMS или Cloaking для повышения производительности за счет прямого доступа к кэшированным данным в линейной памяти, а не через обычные API-интерфейсы DOS.
Кэширование с отложенной записью часто не включалось по умолчанию в программном обеспечении Microsoft (если оно имеется) из-за проблемы потери данных в случае сбоя питания или сбоя, что упрощалось из-за отсутствия аппаратной защиты между приложениями и системой.
Длинные имена файлов VFAT
[ редактировать ]
Длинные имена файлов VFAT (LFN) сохраняются в файловой системе FAT с помощью хитрости: добавление дополнительных записей в каталог перед обычной записью файла. Дополнительные записи помечаются атрибутами «Метка тома», «Система», «Скрытый» и «Только чтение» (что дает 0x0F ), эта комбинация не ожидается в среде MS-DOS и поэтому игнорируется программами MS-DOS и сторонними утилитами. Примечательно, что каталог, содержащий только метки томов, считается пустым и его можно удалить; такая ситуация возникает, если файлы, созданные с длинными именами, удаляются из обычного DOS. Этот метод очень похож на метод DELWATCH, позволяющий использовать атрибут тома для сокрытия файлов, ожидающих удаления, для возможного восстановления в будущем, начиная с DR DOS 6.0 (1991) и выше. Это также похоже на публично обсуждавшийся метод хранения длинных имен файлов в Ataris и Linux в 1992 году. [ 69 ] [ 70 ]
Поскольку более старые версии DOS могли ошибочно принимать имена LFN в корневом каталоге за метку тома, VFAT был разработан для создания пустой метки тома в корневом каталоге перед добавлением каких-либо записей имени LFN (если метка тома еще не существовала). [ номер 13 ]
Каждая фальшивая запись может содержать до 13 символов UCS-2 (26 байтов) при использовании полей в записи, которые содержат размер файла или отметки времени (но не поле начального кластера; для совместимости с дисковыми утилитами поле начального кластера установлено на значение 0. см. в разделе 8.3 «Имя файла» Дополнительные пояснения ). До 20 из этих 13-значных записей могут быть объединены в цепочку, поддерживая максимальную длину 255 символов UCS-2. [ 55 ]
Если позиция последнего символа LFN не находится на границе записи каталога (13, 26, 39, ...), то Терминатор 0x0000 добавляется в следующую позицию символа. Затем, если этот терминатор также не находится на границе, оставшиеся позиции символов заполняются 0xFFFF . Никакая запись каталога, содержащая одиночный терминатор, не будет существовать.
Записи LFN имеют следующий формат:
| Компенсация обмена | Длина (байты) | Описание |
|---|---|---|
| 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 определяет, используется ли эта функция при записи. [ 71 ]
См. также
[ редактировать ]- Сравнение файловых систем
- Назначение буквы диска
- exFAT
- Расширенная загрузочная запись (EBR)
- Файловая система FAT и Linux
- Список файловых систем
- Основная загрузочная запись (MBR)
- Тип раздела
- Хронология операционных систем DOS
- Транзакционно-безопасная файловая система FAT
- Турбо ЖИР
- Загрузочная запись тома (VBR)
Примечания
[ редактировать ]- ^ Перейти обратно: а б с Для максимальной совместимости с MS-DOS/PC DOS и DR-DOS операционные системы, пытающиеся определить формат дискеты, должны проверять все упомянутые последовательности кодов операций по смещению сектора. 0x000 в дополнение к поиску действительного байта дескриптора носителя по смещению сектора. 0x015, прежде чем предположить наличие BPB . Хотя дискеты PC DOS 1.0 не содержат BPB, они начинаются с 0xEB тоже, но не показывает 0x90 по смещению 0x002 . Дискеты PC DOS 1.10 даже начинаются с 0xEB 0x?? 0x90 , хотя они по-прежнему не имеют BPB. В обоих случаях проверка допустимого дескриптора носителя по смещению 0x015 завершится ошибкой (значение 0x00 вместо действительных дескрипторов мультимедиа 0xF0 и выше). Если эти тесты не пройдены, DOS проверяет наличие байта дескриптора носителя в первом байте первой FAT в секторе, следующем за загрузочным сектором (логический сектор 1 на дискетах FAT12/FAT16).
- ^ Перейти обратно: а б с д и Подпись в зачете 0x1FE в загрузочных секторах 0x55 0xAA , то есть 0x55 по смещению 0x1FE и 0xAA по смещению 0x1FF . Поскольку , необходимо предполагать представление с прямым порядком байтов в контексте компьютеров, совместимых с IBM PC , это можно записать как 16-битное слово. 0xAA55 в программах для процессоров x86 (обратите внимание на порядок перестановки), тогда как его нужно было бы записать как 0x55AA в программах для других архитектур ЦП, использующих представление с прямым порядком байтов . Поскольку это неоднократно путалось в книгах и даже в оригинальных справочных документах Microsoft, в этой статье используется побайтовое представление на диске на основе смещения, чтобы избежать любой возможной неправильной интерпретации.
- ^ Перейти обратно: а б с Запись контрольной суммы в загрузочных секторах Atari содержит значение выравнивания, а не само магическое значение . Магическая ценность 0x1234 нигде на диске не хранится. В отличие от процессоров Intel x86 , процессоры Motorola 680x0 , используемые в машинах Atari, используют представление памяти с прямым порядком байтов , и поэтому при вычислении контрольной суммы необходимо учитывать представление с прямым порядком байтов. Как следствие этого, для кода проверки контрольной суммы, работающего на машинах x86, пары байтов необходимо поменять местами перед 16-битным сложением.
- ^ DR-DOS может загружать носители с логическими секторами FAT12/FAT16 с размерами логических секторов до 1024 байт.
- ^ Перейти обратно: а б Следующие функции DOS возвращают эти значения регистров: INT 21h/AH=2Ah «Получить системную дату» вернул значения: CX = год ( 1980 .. 2099 ), DH = месяц (1..12), DL = день (1..31). INT 21h/AH=2Ch «Получить системное время» возвращаемые значения: CH = час (0..23), CL = минута (0..59), DH = секунда (0..59), DL = 1/100 секунды. (0..99).
- ^ Было замечено, что Windows XP создает такие гибридные диски при переформатировании дисков ZIP-100, отформатированных FAT16B, в формат FAT32. Полученные тома имели формат FAT32, но по-прежнему использовали FAT16B EBPB. (Неясно, как Windows определяет расположение корневого каталога на томах FAT32, если использовалась только EBPB FAT16.)
- ^ Перейти обратно: а б Одной из утилит, позволяющей указать желаемое значение заполнителя формата для жестких дисков, является FDISK R2.31 DR-DOS с дополнительным параметром очистки.
/W:246. В отличие от других утилит FDISK , DR-DOS FDISK является не только инструментом создания разделов, но также может форматировать недавно созданные разделы как FAT12 , FAT16 или FAT32 . Это снижает риск случайного форматирования неправильных томов. - ^ Чтобы поддержать сосуществование DR-DOS с PC DOS и несколько параллельных установок DR-DOS, расширение по умолчанию "
IBMBIO␠␠COM"Имя загрузочного файла можно изменить с помощьюSYS /DR:extвариант, где ext представляет новое расширение. Другие потенциальные имена загрузочных файлов DR-DOS, которые следует ожидать в особых сценариях: «DRBIOS␠␠SYS", "DRDOS␠␠␠SYS", "IO␠␠␠␠␠␠SYS", "JO␠␠␠␠␠␠SYS". - ^ Если флаг «грязного выключения» тома по-прежнему сбрасывается при запуске, значит, том не был правильно отключен. Это, например, приведет к тому, что Windows 98 WIN.COM запустит SCANDISK для проверки и исправления потенциальных ошибок логической файловой системы. Если флаг плохого сектора снят, это также приведет к принудительному выполнению сканирования поверхности. Это можно отключить, установив AUTOSCAN=0 в разделе [OPTIONS] файла MSDOS.SYS .
- ^ Перейти обратно: а б с д См. другие ссылки, чтобы узнать о специальных мерах предосторожности в отношении возникновения кластерного значения 0xFF0 на томах FAT12 под MS-DOS/PC DOS 3.3 и выше.
- ^ Перейти обратно: а б Некоторые версии FORMAT , начиная с MS-DOS 1.25 и PC DOS 2.0, поддерживают эту опцию.
/O(для старых первый байт всех записей каталога ), чтобы заполнить 0xE5 вместо использования конечного маркера 0x00 . Тем самым. том оставался доступным в PC DOS 1.0–1.1 , тогда как форматирование занимало несколько больше времени, и более новые версии DOS не могли воспользоваться значительным ускорением, вызванным использованием конечного маркера. 0x00 . - ^ Вот причина, почему 0xE5 имел особое значение в записях каталога.
- ^ Перейти обратно: а б Чтобы избежать потенциальной неправильной интерпретации меток тома каталога с записями VFAT LFN операционными системами, не поддерживающими VFAT, известно, что инструменты DR-DOS 7.07 FDISK и FORMAT явно записывают фиктивные "
NO␠NAME␠␠␠␠" метки тома каталога, если пользователь пропускает ввод метки тома. По умолчанию операционная система будет возвращать ту же строку, если в корне тома не найдена метка тома каталога, но без реальной метки тома, сохраненной в качестве первой записи. (после записей каталога) старые операционные системы могли вместо этого ошибочно воспринимать записи VFAT LFN. - ^ Этот тип атрибута распространения ОС IBM 4680 и 4690 должен иметь значение бита на диске, равное 0, поскольку файлы возвращаются к этому типу, когда атрибуты случайно теряются.
Ссылки
[ редактировать ]- ^ «Файловые системы» . Microsoft TechNet . 2001. Архивировано из оригинала 12 августа 2011 г. Проверено 31 июля 2011 г.
- ^ Перейти обратно: а б Microsoft (15 ноября 2006 г.). Файл CONFIG.TXT на компакт-диске Windows 95, заархивированный 28 января 2013 г. по адресу archive.today. Статья 135481, редакция: 1.1, получено 22 декабря 2011 г.: «Для каждого жесткого диска указывается, следует ли записывать дату последнего доступа к файлам». Даты последнего доступа отключаются для всех дисков при запуске компьютера в безопасном режиме и не сохраняются для дискет по умолчанию.
ACCDATE=drive1+|- [drive2+|-]..." - ^ Бхат, Вашингтон (2010). «Обзор структуры данных FAT файловой системы FAT32». S2CID 58178285 .
{{cite web}}: Отсутствует или пусто|url=( помощь ) - ^ Перейти обратно: а б с д и ж г час я дж к л м н тот «Спецификация файловой системы FAT32 инициативы Microsoft Extensible Firmware Initiative, FAT: общий обзор формата на диске» . Майкрософт . 06.12.2000. Архивировано из оригинала 23 июля 2021 г. Проверено 3 июля 2011 г.
- ^ Перейти обратно: а б с д Хааф, Вильфрид; Миддел, Фрэнк (ноябрь 1987 г.). «Данные на дисках — структуры файлов и дискет в CP/M, MSDOS и TOS: управление файлами в TOS». c't - журнал по компьютерным технологиям . c't картотека (на немецком языке). Том 1987, № 11. Verlag Heinz Heise GmbH & Co. KG . С. 241–246 [246]. ISSN 0724-8679 .
- ^ Перейти обратно: а б с д и ж г час я дж к л м н тот п Чаппелл, Джефф (январь 1994 г.). Шульман, Эндрю; Педерсен, Аморетт (ред.). Внутреннее устройство DOS . Серия программ Эндрю Шульмана (1-е издание, 1-е изд.). Издательская компания Аддисон Уэсли . ISBN 978-0-201-60835-9 . (xxvi+738+iv страниц, 3,5-дюймовая дискета [1] [2] ) Исправления: [3] [4] [5]
- ^ Перейти обратно: а б с д и ж г час я дж к л м н тот п д р с т в v В Руководство по программированию Microsoft MS-DOS 3.1 на английском языке [ Справочное руководство программиста Microsoft MS-DOS 3.1 на английском языке ]. Мюнхен: Markt & Technik Verlag (опубликовано в 1986 г.). 1984. ISBN 3-89090-368-1 . 8411-310-02, 036-014-012.
Что касается инструкции перехода в начале загрузочного сектора: «Определите, является ли первый байт загрузочного сектора E9H или EBIT (первый байт 3-байтового NEAR или 2-байтового короткого перехода) или EBH ( первый байт 2-байтового перехода, за которым следует NOP). Если да, то BPB располагается начиная со смещения 3».
(Примечание. Эта книга содержит много ошибок.) - ^ Перейти обратно: а б Дэниел Б. Седори. Загрузочный сектор персонального компьютера IBM DOS версии 1.00 (1981 г.) . 2 августа 2005 г. ( [6] Архивировано 21 мая 2014 г. в Wayback Machine ).
- ^ Перейти обратно: а б Дэниел Б. Седори. Загрузочный сектор персонального компьютера IBM DOS версии 1.10 (1982 г.) . 29 июля 2005 г. ( [7] Архивировано 21 мая 2014 г. в Wayback Machine ).
- ^ Перейти обратно: а б Кальдера (1997). Машиночитаемый исходный код Caldera OpenDOS 7.01 . Файл DISK.ASM в машиночитаемом исходном коде показывает, что DR-DOS проверяет значение 0x69 тоже.
- ^ Пол, Матиас Р. (20 февраля 2002 г.). «Нужна DOS 6.22 (не OEM)» . Группа новостей : alt.msdos.programmer . Архивировано из оригинала 9 сентября 2017 г. Проверено 14 октября 2006 г.
- ^ Басс, Уолли (14 февраля 1994 г.). «Размер кластера» . Группа новостей : comp.os.msdos.programmer . Архивировано из оригинала 9 сентября 2017 г. Проверено 14 октября 2006 г.
- ^ Перейти обратно: а б с д и ж г час Дэйв Уильямс (1992). Технический справочник программиста для MSDOS и IBM PC . ДОСРЭФ, условно-бесплатная версия от 12.01.1992. ISBN 1-878830-02-3 . ( [8] Архивировано 20 мая 2014 г. на Wayback Machine , доступ осуществлен 8 января 2012 г.). Комментарий: Автор упоминает, что DOS 4.0 проверяет OEM-маркировку, но отрицает, что DOS 3.2 тоже ее проверяет (хотя это так).
- ^ Пол, Матиас Р. (25 августа 2004 г.). «НОВОЛТРК.РЕГ» . www.drdos.org . Архивировано из оригинала 4 марта 2016 г. Проверено 17 декабря 2011 г. [9]
- ^ Перейти обратно: а б «Устранение неполадок дисков и файловых систем» . Microsoft TechNet . 05.11.2005. Архивировано из оригинала 7 июня 2014 г. Проверено 15 июня 2014 г.
- ^ IBM (1983). Технический справочник IBM PC . Комментарий: включает полный список исходного кода ПЗУ BIOS оригинального IBM PC.
- ^ Перейти обратно: а б с д Ханс-Дитер Янковски, Дитмар Рабих, Джулиан Ф. Решке (1992). Профессиональная книга Atari ST-STE-TT . Сайбекс, 4-е издание, 12-я партия. ISBN 3-88745-888-5 , ISBN 978-3-88745-888-1 .
- ^ Seagate Technologies, «Переход на жесткие диски расширенного формата с сектором 4 КБ (архивировано Wayback Machine @Archive.org)», 2010 г. ( [10] ).
- ^ Перейти обратно: а б с д Браун, Ральф Д. (29 декабря 2002 г.). «Список прерываний x86» . Архивировано из оригинала 16 июня 2016 г. Проверено 14 октября 2011 г.
- ^ Перейти обратно: а б с д де Бойн Поллард, Джонатан (2010) [2006]. «Все о блоках параметров BIOS» . Часто встречающиеся ответы . Архивировано из оригинала 26 августа 2016 г. Проверено 2 июня 2014 г.
- ^ Перейти обратно: а б с Справочник программиста Microsoft MS-DOS: версия 5.0 . Майкрософт пресс. 1991. ISBN 1-55615-329-5 .
- ^ Перейти обратно: а б с д и ж г час я дж к «Стандартные форматы гибких дисков, поддерживаемые MS-DOS» . Справка и поддержка Microsoft. 12 мая 2003 г. Архивировано из оригинала 9 января 2015 г. Проверено 11 сентября 2012 г.
- ^ Перейти обратно: а б с Майкрософт (1987–07). Справочник программиста MS-DOS 3.3.
- ^ Перейти обратно: а б с д и ж г час я дж «Объем и файловая структура дисковых картриджей для обмена информацией» . Стандарт ECMA-107 (2-е изд., июнь 1995 г.) . ЭКМА . 1995. Архивировано из оригинала 07 октября 2018 г. Проверено 30 июля 2011 г.
- ^ Перейти обратно: а б с д и ж г час я дж «Информационные технологии -- Объем и файловая структура дисковых картриджей для обмена информацией» . ИСО/МЭК 9293:1994 . ИСО Каталог . 1994. Архивировано из оригинала 17 января 2012 г. Проверено 6 января 2012 г.
- ^ Перейти обратно: а б с д и ж г час я дж «Обработка информации. Объем и файловая структура гибких дисковых картриджей для обмена информацией» . ИСО 9293:1987 . ИСО Каталог . 1987. Архивировано из оригинала 17 января 2012 г. Проверено 6 января 2012 г.
- ^ Перейти обратно: а б с Андрис Брауэр (20 сентября 2002 г.). «Файловая система FAT» . Архивировано из оригинала 6 октября 2011 г. Проверено 16 октября 2011 г.
- ^ Перейти обратно: а б с д и ж г час я дж к л м н тот п д р Патерсон, Тим ; Microsoft (19 декабря 2013 г.) [1983]. «Microsoft DOS V1.1 и V2.0: /msdos/v20source/SKELIO.TXT, /msdos/v20source/HRDDRV.ASM» . ЧМ . Музей истории компьютеров , Microsoft . Архивировано из оригинала 14 августа 2019 г. Проверено 25 марта 2014 г. (Примечание: хотя издатели утверждают, что это будут MS-DOS 1.1 и 2.0, на самом деле это SCP MS-DOS 1.25 и смесь Altos MS-DOS 2.11 и TeleVideo PC DOS 2.11 .)
- ^ Перейти обратно: а б с д и ж г час я дж Збиковски, Марк ; Аллен, Пол ; Балмер, Стив ; Борман, Рубен; Борман, Роб; Батлер, Джон; Кэрролл, Чак; Чемберлен, Марк; Челл, Дэвид; Коули, Майк; Кортни, Майк; Драйфус, Майк; Дункан, Рэйчел; Экхардт, Курт; Эванс, Эрик; Фермер, Рик; Гейтс, Билл ; Гири, Майкл; Гриффин, Боб; Хогарт, Дуг; Джонсон, Джеймс В.; Кермаани, Каамель; Король, Адриан; Кох, Рид; Ландовски, Джеймс; Ларсон, Крис; Леннон, Томас; Липки, Дэн; Макдональд, Марк ; МакКинни, Брюс; Мартин, Паскаль; Мазерс, Эстель; Мэтьюз, Боб; Мелин, Дэвид; Мергентайм, Чарльз; Невин, Рэнди; Ньюэлл, Дэн; Ньюэлл, Тани; Норрис, Дэвид; О'Лири, Майк; О'Рир, Боб ; Олссон, Майк; Остерман, Ларри; Остлинг, Ридж; Пай, Сунил; Патерсон, Тим ; Перес, Гэри; Питерс, Крис; Петцольд, Чарльз ; Поллок, Джон; Рейнольдс, Аарон ; Рубин, Дэррил; Райан, Ральф; Шульмейстерс, Карл; Шах, Раджен; Шоу, Барри; Коротко, Энтони; Сливка, Бен; Смирл, Джон; Стиллмейкер, Бетти; Стоддард, Джон; Тиллман, Деннис; Уиттен, Грег; Йонт, Натали; Зек, Стив (1988). «Технические консультанты». Энциклопедия MS-DOS: версии с 1.0 по 3.2 . Дункан, Рэй; Боствик, Стив; Бургойн, Кейт; Байерс, Роберт А.; Хоган, Том; Кайл, Джим; Летвин, Гордон ; Петцольд, Чарльз ; Рабиновиц, Чип; Томлин, Джим; Уилтон, Ричард; Вулвертон, Ван; Вонг, Уильям; Вудкок, Джоанн (Полностью переработанное издание). Редмонд, Вашингтон, США: Microsoft Press . ISBN 1-55615-049-0 . LCCN 87-21452 . OCLC 16581341 . (xix+1570 страниц; 26 см) (Примечание. Это издание было опубликовано в 1988 году после обширной переработки отозванного первого издания 1986 года другой группой авторов. [11] Архивировано 14 октября 2018 г. в Wayback Machine )
- ^ Перейти обратно: а б «Подробное объяснение загрузочного сектора FAT» . База знаний Майкрософт . 06 декабря 2003 г. Архивировано из оригинала 28 ноября 2011 г. Проверено 16 октября 2011 г.
- ^ Перейти обратно: а б с Лай, Роберт С.; Группа Уэйта (1987). Написание драйверов устройств MS-DOS (2-е изд.). Эддисон Уэсли. ISBN 0-201-60837-5 .
- ^ Перейти обратно: а б с д и ж г час я дж к л м н тот п д р с т Патерсон, Тим ; Microsoft (19 декабря 2013 г.) [1983]. «Microsoft DOS V1.1 и V2.0: /msdos/v20source/DEVDRIV.txt» . Музей истории компьютеров , Microsoft . Архивировано из оригинала 14 августа 2019 г. Проверено 25 марта 2014 г. (Примечание: хотя издатели утверждают, что это будут MS-DOS 1.1 и 2.0, на самом деле это SCP MS-DOS 1.25 и смесь Altos MS-DOS 2.11 и TeleVideo PC DOS 2.11 .)
- ^ Перейти обратно: а б с д и Тим Патерсон (1983). «Взгляд изнутри на MS-DOS» . Байт . Архивировано из оригинала 20 июля 2011 г. Проверено 18 июля 2011 г.
Нумерация начинается с 2; первые две цифры, 0 и 1, зарезервированы.
- ^ Перейти обратно: а б с д PORT-DOS — Руководство пользователя для Apricot Portable . Руководства для пользователя, Великобритания ( [12] Архивировано 22 мая 2013 г. в Wayback Machine ).
- ^ Перейти обратно: а б с д и Джон К. Эллиотт (1998). Форматы дисков DOSPLUS . ( [13] Архивировано 7 июня 2013 г. в Wayback Machine ).
- ^ Перейти обратно: а б с д Мастер BBC 512 . Компьютерные страницы BBC Yellow Pig ( [14] Архивировано 21 мая 2014 г. в Wayback Machine ).
- ^ Корпорация цифрового оборудования. Техническая документация Rainbow 100 MS-DOS 2.01, том 1 (QV025-GZ), список BIOS операционной системы Microsoft MS-DOS (AA-X432A-TV), универсальный драйвер диска, стр. 1–17. 1983.
- ^ «Подробное объяснение загрузочного сектора FAT» . Корпорация DEW Associates. 2002. Архивировано из оригинала 26 сентября 2011 г. Проверено 16 октября 2011 г.
- ^ Тьяги, Тарун (31 октября 2004 г.). «Размер кластеров в файловых системах FAT и NTFS». Восстановление данных с программированием и без него . Нью-Дели, Индия: Книги Гарднера. п. 4. ISBN 978-81-7656-922-4 . Архивировано из оригинала 3 декабря 2021 г. Проверено 3 декабря 2021 г.
- ^ Дэниел Б. Седори. Подробные примечания к «флагу неправильного завершения работы» в MS-Windows . 04.12.2001. ( [15] Архивировано 21 мая 2014 г. в Wayback Machine ).
- ^ Перейти обратно: а б с д и «Windows 98 Resource Kit — Глава 10 — Диски и файловые системы» . Microsoft TechNet . 1998. Архивировано из оригинала 1 мая 2012 г. Проверено 16 июля 2012 г.
- ^ Перейти обратно: а б с д Шульман, Эндрю; Браун, Ральф Д .; Макси, Дэвид; Михелс, Раймонд Дж.; Кайл, Джим (1994) [ноябрь 1993 г.]. Недокументированная DOS: Руководство программиста по зарезервированным функциям и структурам данных MS-DOS - расширено и включает MS-DOS 6, Novell DOS и Windows 3.1 (2-е изд.). Ридинг, Массачусетс: Эддисон Уэсли . п. 11 . ISBN 0-201-63287-Х . (xviii+856+vi страниц, 3,5-дюймовая дискета) Исправления: [16] [17]
- ^ Питер Нортон (1986). Внутри IBM PC, переработанное и расширенное , Брейди. ISBN 0-89303-583-1 , с. 157.
- ^ Перейти обратно: а б с Андрис Брауэр . «FAT под Linux» . Архивировано из оригинала 1 июля 2014 г. Проверено 20 мая 2014 г.
- ^ Андрис Брауэр (20 сентября 2002 г.). "ТОЛСТЫЙ" . Архивировано из оригинала 17 декабря 2017 г. Проверено 11 января 2012 г.
- ^ Перейти обратно: а б с Компьютерные продукты Сиэтла (1981). «Дополнение к SCP 86-DOS 1.0» (PDF) . Архивировано (PDF) из оригинала 3 октября 2012 г. Проверено 10 марта 2013 г.
- ^ Перейти обратно: а б с д и ж г час я дж к л м н тот п д р с т в v В х и С аа аб и объявление но из в ах есть также и Пол, Матиас Р. (30 июля 1997 г.) [1 мая 1994 г.]. NWDOS-TIPs — советы и подсказки для Novell DOS 7, с просмотром недокументированных подробностей, ошибок и обходных путей . MPDOSTIP (на немецком языке) (3-е изд.). Архивировано из оригинала 5 ноября 2016 г. Проверено 11 января 2012 г. (Примечание. NWDOSTIP.TXT — это всеобъемлющая работа по Novell DOS 7 и OpenDOS 7.01 , включая описание многих недокументированных функций и внутренних устройств. Это часть еще более обширной авторской коллекции MPDOSTIP.ZIP, которая поддерживалась до 2001 года и распространялась на многих сайтах по адресу: время. Предоставленная ссылка указывает на более старую версию файла, преобразованную в HTML.) [18]
- ^ IBM. Руководство пользователя ОС 4690, версия 5.2 , документ IBM SC30-4134-01, 10 января 2008 г. ( [19] Архивировано 25 января 2022 г. на Wayback Machine ).
- ^ Перейти обратно: а б Патерсон, Тим ; Microsoft (19 декабря 2013 г.) [1983]. «Microsoft DOS V1.1 и V2.0: /msdos/v20source/FORMAT.TXT» . Музей истории компьютеров , Microsoft . Архивировано из оригинала 14 августа 2019 г. Проверено 25 марта 2014 г. (Примечание: хотя издатели утверждают, что это будут MS-DOS 1.1 и 2.0, на самом деле это SCP MS-DOS 1.25 и смесь Altos MS-DOS 2.11 и TeleVideo PC DOS 2.11 .)
- ^ Перейти обратно: а б Шустек, Лен (24 марта 2014 г.). «Ранний исходный код Microsoft MS-DOS» . Жемчужины программного обеспечения: серия исторических исходных кодов Музея компьютерной истории. Архивировано из оригинала 10 августа 2019 г. Проверено 29 марта 2014 г. (Примечание. Хотя автор утверждает, что это будут MS-DOS 1.1 и 2.0, на самом деле это SCP MS-DOS 1.25 и смесь Altos MS-DOS 2.11 и TeleVideo PC DOS 2.11 .)
- ^ Перейти обратно: а б Левин, Рой (25 марта 2014 г.). «Microsoft делает исходный код MS-DOS и Word для Windows общедоступным» . Официальный блог Microsoft . Архивировано из оригинала 28 марта 2014 г. Проверено 29 марта 2014 г. (Примечание. Хотя автор утверждает, что это будут MS-DOS 1.1 и 2.0, на самом деле это SCP MS-DOS 1.25 и смесь Altos MS-DOS 2.11 и TeleVideo PC DOS 2.11 .)
- ^ JEIDA/JEITA/CIPA (2010). «Стандарт Ассоциации производителей камер и продуктов обработки изображений, CIPA DC-009-Translation-2010, Правила проектирования файловой системы камеры: DCF, версия 2.0 (издание 2010 г.)» (PDF) . Архивировано из оригинала (PDF) 30 сентября 2013 г. Проверено 13 апреля 2011 г.
- ^ Перейти обратно: а б с д и ж г час я дж к л м н тот п д Кальдера (1997). Машиночитаемый исходный код Caldera OpenDOS 7.01 . Файл FDOS.EQU в машиночитаемом исходном коде имеет эквиваленты для соответствующих записей каталога.
- ^ Джон К. Эллиотт (1998). Форматы дисков CP/M 4.1 . ( [20] Архивировано 26 августа 2014 г. на Wayback Machine ): «CP/M 4.1 (DOS Plus [1.2]) позволяет использовать две файловые системы — CP/M и DOS. Поставляемая версия [...] Amstrad PC1512 не может работать с дискетами размером более 360 КБ (CP/M) / 1,2 МБ (DOS) или разделами жесткого диска размером более 32 МБ [...]. Файловая система DOS может быть FAT12 или FAT16. Формат такой же, как в PCDOS 2.11, за исключением: Байт 0Ch записи каталога [...] содержит четыре «атрибута пользователя» F1'-F4' [...] DRDOS. Пароли в стиле - не поддерживаются».
- ^ Перейти обратно: а б винДачи (06 января 1998 г.). «Спецификация длинного имени файла» . Архивировано из оригинала 20 апреля 2001 г. Проверено 13 марта 2007 г.
- ^ Хенк Келдер. FAT32.TXT для FAT32.IFS версии 0.74 . ( «@Макарло, Инк» . Архивировано из оригинала 30 марта 2012 г. Проверено 14 января 2012 г. ). Комментарий: В этой старой версии файла README все еще обсуждается старый 0xEA и Магические значения 0xEC .
- ^ Хенк Келдер (2003). FAT32.TXT для FAT32.IFS версии 0.9.13." ( [21] Архивировано 25 января 2022 г. на Wayback Machine ): "Этот байт [...] не изменяется при работе в Windows 95 и более поздних версиях с помощью SCANDISK или DEFRAG. . [...] Если другая программа устанавливает значение 0x00 для файла, содержащего советники, эти советники больше не будут найдены только с помощью вызовов DosFindFirst/Next. Другие вызовы OS/2 для получения EA (DosQueryPathInfo, DosQueryFileInfo и DosEnumAttribute) не полагаются на этот байт. Также может произойти и обратное. [...] В этой ситуации снизится только производительность сканирования каталогов. Обе ситуации [...] исправляются CHKDSK ».
- ^ Нетлабс. FAT32.IFS Wiki и исходные коды . ( [22] Архивировано 11 мая 2013 г. в Wayback Machine ).
- ^ Перейти обратно: а б ИБМ. Руководство по программированию ОС 4690, версия 5.2 , документ IBM SC30-4137-01, 6 декабря 2007 г. ( [23] Архивировано 25 января 2022 г. на Wayback Machine ).
- ^ Перейти обратно: а б с д и ж г час я дж к л м н Серия справочников для разработчиков OpenDOS — Руководство по системе и программисту — Руководство программиста . Caldera, Inc., август 1997 г. Номер детали Caldera 200-DODG-003. Архивировано из оригинала 07.10.2017 . Проверено 20 мая 2014 г. (Напечатано в Великобритании.)
- ^ Боб Игер, Tavi Systems (28 октября 2000 г.). Реализация расширенных атрибутов файловой системы FAT . ( [24] Архивировано 13 июня 2006 г. в Wayback Machine ).
- ^ IBM (2003). Информация об уникальных атрибутах распределения файлов ОС 4690 , документ IBM R1001487, 30 июля 2003 г. ( «Информация IBM об уникальных атрибутах распространения файлов ОС 4690 — США» . Архивировано из оригинала 21 мая 2014 г. Проверено 20 мая 2014 г. ): «[...] типы файлов хранятся в части «Зарезервированные биты» структуры каталогов файлов PC-DOS [...] только 4690 уважает и сохраняет эти атрибуты. Различные операционные системы, отличные от 4690, предпринимают разные действия, если эти биты включаются [...] при копировании с дискеты, созданной в системе 4690 [...] PC-DOS и Windows 2000 Professional скопируют файл без ошибок и обнулят биты OS/2 [.. .] 1.2 [...] откажется для копирования файла, если [...] сначала не запустить CHKDSK /F для файла. После [...] CHKDSK он скопирует файл и обнулит биты [...] при копировании [. ...] обратно в систему 4690, [...] файл будет скопирован как локальный файл».
- ^ IBM. 4690 сохранять и восстанавливать атрибуты распределения файлов . Документ IBM R1000622, 31 августа 2010 г. ( «IBM 4690 сохраняет и восстанавливает атрибуты распространения файлов — США» . Архивировано из оригинала 21 мая 2014 г. Проверено 20 мая 2014 г. ).
- ^ «Ограничения файловой системы FAT32» . База знаний Майкрософт . 26 марта 2007 г. Архивировано из оригинала 15 августа 2011 г. Проверено 21 августа 2011 г.
Кластеры не могут иметь размер 64 килобайта или больше.
- ^ Дункан, Рэй (1989). «Цели разработки и реализация новой высокопроизводительной файловой системы» . Системный журнал Microsoft. Архивировано из оригинала 16 июля 2011 г. Проверено 20 мая 2014 г. [Примечание. Этот конкретный текстовый файл содержит ряд ошибок оптического распознавания символов; например, «Рэй» — правильное имя автора; а не «Рой», как показано в тексте.]
- ^ Чен, Раймонд (июль 2006 г.). «Microsoft TechNet: краткая и неполная история FAT32» . Журнал Microsoft TechNet. Архивировано из оригинала 18 ноября 2008 г. Проверено 20 мая 2014 г.
- ^ Перейти обратно: а б Лес Белл; Associates Pty Ltd (02.09.1996) [1990]. «Высокопроизводительная файловая система OS/2» . Консультант по поддержке ПК . Архивировано из оригинала 1 марта 2014 г. Проверено 24 июня 2014 г.
- ^ Перейти обратно: а б Бриджес, Дэн (февраль 1996 г.). «Внутри высокопроизводительной файловой системы. Часть 2/6: Введение» . Значительные биты, Brisbug PC User Group Inc. Архивировано из оригинала 23 сентября 2015 г. Проверено 24 июня 2014 г.
- ^ Натюрлих! (24 марта 1992 г.). «Получение более длинных имен файлов из GEMDOS» . comp.sys.atari.st.tech. Архивировано из оригинала 24 апреля 2014 г. Проверено 5 мая 2014 г.
- ^ Торвальдс, Линус (23 декабря 1992 г.). «Длинные имена файлов» . комп.os.minix. Архивировано из оригинала 23 апреля 2014 г. Проверено 5 мая 2014 г.
- ^ «mount(8): смонтировать файловую систему» . Справочная страница Linux . Архивировано из оригинала 5 мая 2014 г. Проверено 20 мая 2014 г.
Внешние ссылки
[ редактировать ]- 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
Стандарты Ecma International |
|---|
ISO Стандарты по номеру стандарта |
|---|