MMCA FAT16 File System Specification -...

TheMultiMediaCard

FAT16 File System Specification

Version 1.0

MMCA Technical Committee

MultiMediaCard System

Revision History

Version Date Section/ Page Changes compared to previous issue

0.1 all Initial file system spec proposal to MMCAOriginator:MMCA FS workgroupAuthor:Juha Liinamaa

1.0 03/03 all Conversion to MMCA look and feel formats

2 MultiMediaCard FAT16 File System Specification Version 1.0 Official Release (c) March 2003 MMCA


You acknowledge that the attached standard (the “Standard”) is provided to you on an “AS IS” basis.MULTIMEDIACARD ASSOCIATION (“MMCA”) MAKES NO EXPRESS, IMPLIED ORSTATUTORY WARRANTIES AND EXPRESSLY DISCLAIMS THE WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT OF THIRD PARTY RIGHTS. MMCA SHALL NOT BE LIABLE FOR (I)TECHNICAL OR EDITORIAL ERRORS OR OMISSIONS CONTAINED WITHIN THESTANDARD, OR (II) ANY INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIALDAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS OR LOSS OF USE)RESULTING FROM THE FURNISHING, PERFORMANCE OR USE OF THE STANDARD,EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Copyright (c) March 2003 MultiMediaCard Association, 19672 Stevens Creek Blvd., #404,Cupertino, CA 95014-2465. World rights reserved.

No part of this publication may be transmitted, reproduced or distributed in any way, including butnot limited to photocopying, electronic copying, magnetic or other recording, without the priorwritten consent of MMCA.

MultiMediaCard FAT16 File System Specification Version 1.0 Official Release (c) March 2003 MMCA 3


Table Of Contents

1 Introduction ............................................................................................................................. 7

2 Physical CHS geometry ........................................................................................................... 7

3 Master Boot Record ................................................................................................................. 93.1 Partition entry format ......................................................................................................... 103.2 Address translations ............................................................................................................ 11

4 File system............................................................................................................................... 124.1 Partition Boot Record ......................................................................................................... 124.2 Variable parameters in PBR ............................................................................................... 134.3 Miscellaneous notes on allocation tables and PBR ............................................................ 15

5 Directory entries .................................................................................................................... 175.1 Long filename support ........................................................................................................ 175.2 Filename character sets ....................................................................................................... 185.3 FAT/VFAT16 caveats ........................................................................................................ 195.4 Example of long filename entries ....................................................................................... 195.5 Example of file system memory layout .............................................................................. 20

Appendix A: Abbreviations ........................................................................................................... 23

Appendix B: References ................................................................................................................. 24


MultiMediaCard System Introduction

1 Introduction

Purpose of this document is to define the details of FAT16 file system for MultiMediaCards’ user data area.First of all, various FAT systems have their roots in magnetic media (floppy disks and hard drives). With thatbackground, FAT file system introduces some need to relate the byte-unit linearly addressed MultiMediaCardand conventional magnetic media. In order to maintain consistency at all levels, this document deals with thefollowing specifics:

- CHS geometry: how to translate the card characteristics into the conventional CHS geometry of magnetic media

- Master Boot Record (partitioning): how and why to introduce the MultiMediaCard as logical hard drive(s), conversions between physical and logical addresses and addressing modes

- Partition Boot Record(s), aka partition boot sector: how to define the actual FAT16 file system within a partition

- Directory entries: how to create files and directories (with conventional 8+3 filenames)- Optional long filename support (VFAT): how to avoid breaking inter operability between sys-

tems that do support VFAT and those that don’tCHS geometry is used as a basis for all calculations to maintain consistency throughout all addressing modes.

2 Physical CHS geometryThe goal of this chapter is to define a way to calculate a physical (media-based) CHS geometry for an arbi-trary card with the following guidelines:

- Calculated CHS should reflect card properties and potential as they are expressed in the card CSD register and MultiMediaCard System Specification

- Singular conversions between addressing modes (CHS, linear sector and linear card address)- Simple and efficient conversion methods- Minimal waste of card memory capacity in address conversions

In order to simplify the expressions, the following notations are defined. Practical implementation of thesenotations should be straightforward on any platform.

- floor(x): closest integer ≤ x- ceil(x): closest integer ≥ x- ceil2(x): closest even integer ≥ x- rem(x, y): remainder of integer division (x/y). The remainder, x and y are ≥ 0- min(r): smallest value found in a finite-length range of numbers- max(r): largest value found in a finite-length range of numbers

The following table summarizes the all the factors that need to be considered at this point

Table 1: Physical CHS calculation parameters

Acronym Explanation Range Unit

M Card memory capacity as expressed in the card CSD register 98304 to 232 byteW Sector Size 512 byteS Number of Sectors per Head 32 sector


Introduction MultiMediaCard System

Min(M) is the smallest card capacity for which the FAT16 system described in this document can be imple-mented; reasons for this limitation become more obvious later on. Max(M) is ultimately limited by the MultiMediaCard bus protocol itself with its byte-based 32-bit addressing.Thus, maximal capacity is 4GB.Sector size (W) was defined to be 512 bytes as it is the ‘de facto’ standard of current disks, file system imple-mentations and MultiMediaCards. However, if the card does not support data transfer operations at 512-bytegranularity, host SW must provide support for the 512-byte sector size.Limitations on parameters C, H and S are introduced to maintain compatibility with the traditional BIOSint13h hard drive interface of PC computers. Parameter H is forced to even values in order to maintain consis-tency with disk drives; it makes sense that both sides of “disk platters” are used in conventional disk drives.Parameter S is fixed to 32 sectors for a number of reasons. It simplifies calculations, neatly divides the cardcapacity to fixed 16kB chunks and is sufficient to address the maximal card capacity:

Furthermore, it is the maximum number of card write blocks in the smallest card erase unit (erase sector).Assuming 512-byte write block and powers-of-two logic in the card memory hierarchy, it exactly covers one

P Number of Sectors on media (aka Number of Physical sectors, aka LBA’s)

floor(min(M)/W) tofloor(max(M)/W)

sector

H Number of Heads per Cylinder [2, 4, 6,..., 256] headC Number of Cylinders on media (aka Number of Physical cylin-

ders)[3, 4, 5,..., 1024] cylinder

Table 1: Physical CHS calculation parameters

Acronym Explanation Range Unit

max C( ) max H( ) S W 1024⁄( )KB⋅ ⋅ ⋅ 1024 256 32 0.5KB⋅ ⋅ ⋅ 4194304KB 4GB= = =



or more card erase units. The variable parameters are calculated as follows:

Equation 1: Number of physical sectors

Equation 2: Number of physical heads

Equation 3: Number of physical cylinders

Thus, the CHS geometry may waste some capacity because all existing platforms do not allow partial cylin-ders. Furthermore, address translations remain straightforward if CHS addressing is allowed to be the limit-ing factor. Amount of wasted capacity is minimized by minimizing the number of heads. Consequently,number of cylinders is maximal.

3 Master Boot RecordPartition table resides at the very beginning of the media. It's total size is 16kB (32 sectors = 1 head). Thepartition table contains Master Boot Record (MBR) which defines the layout of file system(s) on the media.Master boot record is the very first sector on the media. The other sectors in the partition table may containMaster Boot Code or some proprietary information which is “don't care”, from standardization point of view.The MBR itself is arranged as follows:

Table 2: Master Boot Record structure

Byteposition

Length(bytes) Entry Description Value / Range

0x000 432 Optional MBR code (“don't care”)0x1B0 14 Media ID entry (Defined in System Spec 3.0, chapter 11)0x1BE 16 Partition Table Entry (see below)0x1CE 16 Partition Table Entry (see below)0x1DE 16 Partition Table Entry (see below)0x1EE 16 Partition Table Entry (see below)0x1FE 1 Signature 0x55

P floor MW----- =

H ceil2 PS max C( )⋅---------------------------- =

C floor PS H⋅------------ =



3.1 Partition entry format

Every partition entry has the following fields (cylinder example values refer to 1st partition):

All formatted partitions are based on 16-bit FAT entries and may employ VFAT for long filename support. Allsector numbers are stored in Little-Endian format (least significant byte first). All memory capacity relatedparameters depend on the CHS geometry defined in the previous chapter. As implied by the table, all parti-tions must be aligned to full cylinders. Partition allocation does not have to be contiguous, but partitions mustnot overlap and their starting/ending cylinder values must not exceed the value (C-1) defined in previouschapter. Those values with an acronym are inherited to Partition Boot Record one way or another.Values in unused partition entries are all zeroes.“Extended” partitions are beyond the scope of this document. Such partitions would require definition ofnested Secondary Master Boot Record before it can be divided to logical partitions. Since supporting this fea-

0x1FF 1 Signature 0xAA

Table 3: Partition entry

Byteposition

Length(bytes) Description Value / Range Acronym

0x0 1 boot descriptor 0x00 (non-bootable),0x80 (bootable)

BF

0x1 1 Partition start head 00x2, bits[5:0] 6/8 Partition start sector 10x2, bits[7:6] 2/8 Partition start cylinder MSB:

bits[9:8]1 to (C-2) BN

0x3 1 Partition start cylinder, bits[7:0]0x4 1 File system descriptor

0 = empty4 = DOS 16-bit FAT < 32MB6 = DOS 16-bit FAT > 32MB

Other values indicate non-standard 3rd party file sys-tem

0x5 1 Partition end head H-10x6, bits[5:0] 6/8 Partition end sector S 0x6, bits[7:6] 2/8 Partition end cylinder MSB:

bits[9:8]1 to (C-1) EN

0x7 1 Partition end cylinder,bits[7:0]

0x8 4 First sector position relative to the beginning of media (zero-based)

B0*H*S + 0*S +1 –1 = B0*H*S

ON

0xC 4 Number of sectors in partition (E0-B0+1)*H*S PN

Table 2: Master Boot Record structure

Byteposition

Length(bytes) Entry Description Value / Range



ture adds to the complication and is not crucial in terms of inter operability, its use is forbidden.

3.2 Address translations

While all partitions reside on the same physical media, purpose of partitioning is to introduce them as separatepseudo devices which have individual file systems and logical addressing. File system addressing is partition-based. To summarize, partitions introduce the following division between addresses:

- Logical address: partition-based, either linear or CHS. It is only able to deal with sectors within a single partition

- Physical address: media-based. It is capable of addressing the whole media capacity across par-titions, either linearly or via CHS

Per-partition logical CHS limits are defined in the following table. It is the “apparent” CHS geometry whichwill be applied when actual file system is created to a partition.

Since partitions were previously forced to cylinder boundaries, conversion between physical and logical CHSaddresses remains simple: only cylinder offset needs correction. When converting linear addresses betweenphysical and logical, offset is corrected by parameter ON.Conversions between linear address and CHS address are computed as follows (p = arbitrary linear, c = arbi-trary cylinder, h = arbitrary head, s = arbitrary sector):

Equation 4: Arbitrary CHS-to-linear address conversion

Equation 5: Arbitrary linear-to-CHS address conversion

Card address is calculated from arbitrary physical address by multiplying with W.

Table 4: Logical CHS parameters

Acronym Description Range / Value Unit

Cn Number of cylinders in partition EN-BN+1 CylinderHN Number of heads per cylinder in partition H HeadSN Number of sectors per track in partition S Sector

p c H S⋅ ⋅ h S⋅ s 1–+ +=

c floor PS H⋅------------ =

h floor p c H S⋅ ⋅–S

---------------------------- =

s p c H S⋅ ⋅– h S⋅ 1+–=



4 File systemEach partition will have its own FAT16 file system. Therefore, all the parameters described are logical andonly apply to the partition under consideration.With FAT16, the partition is roughly divided into two areas:

- System area: reserved sectors (including boot sector, aka Partition Boot Record), file allocation tables (2pcs) and root directory entries (512pcs)

- User data area: divided into allocation units (clusters)Since there are several ways to arrange the system and data area usage, the goal of this chapter is to define aFAT system according to following guidelines:

- Define a singular way to arrange system and data area usage- Adhere to CHS and it’s 16kB boundaries for efficiency and consistency- Minimize wasted capacity (cluster size)

4.1 Partition Boot Record

The partition Boot Record is the first sector in the partition in (logical) linear address 0. Fields with a definedacronym are computed or otherwise used later on.

Table 5: PBR structure

Byteposition

Length (bytes) Description Range/Value Acronym

0x0 3 Jump command. NOTE: x86 machine language spe-cific, must not be changed

0xEB 0xXX 0x90

0x3 8 OEM name. NOTE: MS Windows apparently trashes this field on removable media

Don’t care

0xB 2 Bytes Per Sector W0xD 1 Sectors per Cluster [20, 21,..., 27] sc 0xE 2 Reserved Sectors (including this PBR) [2, 4, 6,..., S] r0x10 1 Number of FATs 20x11 2 Number of root directory entries (32 bytes each) 512 E0x13 2 Number of sectors on partition 0 (if partition type 6)

PN (if partition type 1)0x15 1 Media descriptor 0xF8 (hard disk)0x16 2 Sectors Per Fat 1 to 256 sf 0x18 2 Sectors Per Track S0x1A 2 Number of Heads H0x1C 4 Number of Hidden sectors (part. Offset) ON 0x20 4 Extended number of sectors on partition PN (if partition type 6)

0 (if partition type 1)0x24 1 Drive number BF (partition entry)0x25 1 Reserved 0



As can be seen, lots of information in this record is inherited from physical CHS geometry and partition tableentry. Note: number of logical cylinders can be calculated either from these values or from respective parti-tion entry values; PBR has inherited the needed parameters from partition entry. Using MBR, the logicalnumber of cylinders CN is:

Equation 6: Number of logical cylinders in partition

4.2 Variable parameters in PBR

At this point, we have three degrees of freedom in our FAT arrangement, namely reserved sectors (r), sectorsper FAT (sf) and sectors per cluster (sc). However, these parameters are not entirely independent of each otherand each has certain limitations.In the following, reserved sectors and the two FAT tables are combined to parameter hF which shall fulfill theequation

Root directory entries (512pcs) take exactly one head; each RDE is 32bytes, 512*32/W = 512*32/512 = 32sectors = 1 head.Having these requirements in place aligns all our major file system components (reserved sectors + FATs, rootdirectory entries and user data area) to 16kB head boundaries, hopefully increasing performance a little.Because there are two identical FATs, r is implicitly an even integer (since S is even) to satisfy the condition

0x26 1 Extended boot signature 0x290x27 4 Volume serial number PSN from card CID +par-

tition index (0 to 3)0x2B 11 Volume label (example mmcform11) ASCII string w/o NULL,

SP padding(“mmcform11 “)

0x36 8 File system type ASCII string:(“FAT16”)

0x3E 448 Optional partition boot code Don’t care0x1FE 1 Signature 0x550x1FF 1 Signature 0xAA

Table 5: PBR structure

Byteposition

Length (bytes) Description Range/Value Acronym

CN EN BN– 1+=

S hF⋅ r 2 sF⋅+=



rem(r +2sF, S) = 0. Thus, it is always guaranteed that there is at least 1 “free” sector between PBR and FATswhich can optionally contain proprietary information and non-x86 boot code. However, from standardizationpoint-of-view, data in reserved sectors other than the PBR is “don’t care”.Each FAT entry is 16bits = 2bytes, yielding W/2 = 256 cluster entries per sector. Keeping in mind that the firsttwo clusters are reserved, the combined partition capacity must satisfy the following condition

Equation 7: Partition capacity equation

Thus, condition for hF is clearer, but we still have three degrees of freedom (hF, r and sc) at this point. How-ever, our earlier definitions and the FAT16 system itself imposes some restrictions:

Equation 8: Partition capacity equation restrictions

Keeping in mind the definition of hF, condition r = 2 represents the ideal case of FAT size. Thus, equation 4-2simplifies to equation 4-4 (dN is actual number of data clusters in the partition):

Equation 9: Restricted partition capacity equations

Additional limitation to number of actual data clusters dN is imposed by the fact that in addition to clusterindices 0 and 1, some other indices are restricted as well: 0xFFF0 to 0xFFF6 are reserved, 0xFFF7 denotes

CN H hF– 32 E⋅S W⋅--------------–⋅

S⋅W 2

-------S hF⋅ r–

2---------------------⋅ 2–

sc⋅– sc< ⇒

CN H hF– 1–⋅( ) 32⋅ 128 32 hF 128 r⋅–⋅ ⋅ 2–( ) sc⋅– sc< ⇒

32 CN H⋅⋅ 32 hF 32–⋅ 4096– sc hF 128 r sc 2 sc⋅+⋅ ⋅+⋅ ⋅– sc< ⇒

4096 sc⋅( ) hF 32 CN H 128 r 1+⋅( ) sc 32–⋅+⋅ ⋅>⋅ ⇒

hF32 CN H 128 r 1+⋅( ) sc 32–⋅+⋅ ⋅

4096 sc⋅ 32+------------------------------------------------------------------------------------>

hF 17≤

r 2 4 6 … S, , , ,[ ] S,∈ 32=sc 20 21 … 27, , ,[ ]∈

hF ceil32 CN H 257 sc 32–⋅+⋅ ⋅

4096 sc 32+⋅--------------------------------------------------------------- =

sc 20 21 … 27, , ,[ ]∈

hF 17<

dN floor32 CN H 32 hF 32–⋅+⋅ ⋅

sc------------------------------------------------------------- 65518≤=



unusable cluster and 0xFFF8 to 0xFFFF signify end of file allocation chain. Thus, maximum number ofactual data clusters is (65536 – 18 = 65518). This has to be taken into account at hF = 17 boundary.At this point, the sensible thing to do is to experiment with the various cluster sizes (sC). Cluster size shouldbe as small as possible to avoid capacity waste. So, there will be a maximum of eight iterations whichrepeated until calculated hF and dN meet their respective criteria.After the iterations, PBR parameter sC is already known. Parameters sF and r are computed from dN as fol-lows:

Equation 10: Computation of sF and r

4.3 Miscellaneous notes on allocation tables and PBR

- Cluster entries 0 and 1 must have values 0xFFF8 and 0xFFFF, respectively- Both FAT tables are identical- Free cluster entries will have value 0- Possible extraneous cluster entry values at the end of FAT tables are considered “don’t care”. For

purposes of inter operability, no specific value may be assumed- Cluster entry-to-logical linear address conversions are calculated according to EN ISO

29293:1989, chapter 6.2.1- Data space allocation from FAT is performed according to EN ISO 29293:1989, chapter 6.4.2

Table 4-2 summarizes cluster values within valid data cluster indices (2 to dN +1):

Table 4-3 summarizes the cluster values (if any) in special allocation table indices:

Table 1: Cluster values within valid data cluster indices (2 to dN +1)

Value/Range Description

0x0000 Indicates free cluster0x0001 Invalid value, must not be used0x0002 to (dN +1) Indicates allocated cluster. The value stored is the index of next cluster entry in an allocation chain(dN +2) to 0xFFF0 Invalid values, must not be used. Such values would point beyond the partition's data area0xFFF0 to 0xFFF6 Reserved values, must not be used0xFFF7 Indicates a bad (malfunctioning) cluster0xFFF8 to 0xFFFF Indicates the end of an allocation chain

Table 2: Cluster values in special indices

Indices Value/Description

0x0000 0xFFF8 (F8 is the media byte from PBR)0x0001 Always 0xFFFF

sF ceildN 2+

256--------------- =

r S rem 2 sF⋅ S,( )– 32 rem 2 sF⋅ 32,( )–= =



The following chart provides a simple example how cluster chains are formed within allocation table and howcluster indices are mapped to data area sectors. The first logical LSN of data area – “Beginning of data area”in the chart – is calculated from PBR as the sum of (r + number_of_fats*sf + 32). Note that cluster chainsneed not be contiguous or in ascending order.

(dN +2) to 0xFFEF Last sector of FAT may contain extraneous cluster entries due to sector-boundary allocation. Val-ues of those extraneous cluster entries should be 0x0000. However, any file system driver should not rely on these values being 0x0000. Instead, it should always be aware of the total number of data clusters (dN)

0xFFF0 to 0xFFF6 Reserved indices/values, must not be used for allocation. Refer to previous table0xFFF7 Reserved index/value, must not be used for allocation. Refer to previous table0xFFF8 to 0xFFFF Reserved indices/values, must not be used for allocation. Refer to previous table

Table 2: Cluster values in special indices

Cluster index Cluster values0 0xFFF8 0xFFFF 0x0004 0x0000 0x0005 0xFFF8 0x0000 0x0000

8 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0xFFF7

16 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000

...

...

..., dN +1> dN +1 Don't care

Data Cluster 2 Data Cluster 3 Data Cluster 4 Data Cluster 5Data Cluster 6 Data Cluster 7 Data Cluster 8 Data Cluster 9...

Start of allocation chain (f rom directory entry)

End of chain markerFree cluster

Bad cluster

Beginning of data area.1 cluster = sc consecutive sectors


MultiMediaCard System Directory entries

5 Directory entries

Directory entry structure shall be used according to EN ISO 29293 with the following clarification: for adirectory, the file size field must be zero. The table below describes the directory entry fields, including somenotes.

5.1 Long filename support

VFAT16 long filename support is built on top of regular FAT16 by using extra directory entries which have alltheir attribute bits (Volume, Directory, Read-only, Archive). Systems without long filename support shall

Table 6: Structure of directory entries

Offset Length(bytes) Notes

0x0 8 Blank-padded filename. First character is set to E5h for deleted files (05h for pending delete files under Novell DOS / OpenDOS)

0x8 3 Blank-padded file extension0xB 1 Attributes0xC 10 MS-DOS 1.0-6.22: reserved

DR DOS: used to store file password / ownerNovell DOS 7: DELWATCH dataMS-DOS 7/Windows95: additional file times

0x16 2 Time of creation or last update, bits[15:11]: hours (0-23)[10:5]: minutes[4:0]: seconds/2

0x18 2 Date of creation or last update, bits[15:9] year – 1980[8:5] month[4:0] day

0x1A 2 Starting cluster number0x1C 4 File size

Table 7: Format of MS-DOS 7/Windows95 additional file times


0x0 1 Reserved (Windows NT –specific?)0x1 1 10-millisecond units pas creation time below (Windows NT –specific?)0x2 2 File creation time0x4 2 File creation date0x6 2 Last-access date0x8 2 FAT32: high word of starting cluster number. 0x0000 for VFAT16


Directory entries MultiMediaCard System

ignore such entries. Details of long filename directory entry are as follows:

Long filename entries shall always be stored right prior to the short filename entry. The short filename check-sum byte is computed by adding up the eleven bytes of the short filename, rotating the intermediate sum rightone bit before adding the next character. In pseudocode:

Byte sum=0;I=0;While (I < 11)

{rotate (sum);sum += shortname [I];I++;}

5.2 Filename character sets

Short filenames must be all uppercase. Any combination of characters and numbers is valid, a blank (ASCIIcode 0x20h), as well as all ASCII characters above 0x7F, and the following special characters:$ % ' - _ @ ~ ` ! ( ) ^ # &The following additional characters are valid in long filenames, but are not valid in 8.3 filenames:+ , ; = [ ]Long filenames are stored in 16-bit Unicode format, in practice meaning that there is 0x00 after the actualASCII characters. Long filenames are terminated by an Unicode NULL (0x0000). Short filenames are gener-ated from long filenames by:

• Deleting any invalid characters, including . " / \ [ ] : ; = ,

• Removing extra periods (.) from the filename. The string after final period is considered extension and is truncated to maximum three (3) characters if the characters are valid and do not contain blanks in the mid-

Table 8: Format of long filename directory entry


0x0 1 LFN record sequence and flags, bits[5-0]: sequence number[6:6]: set if last long-filename record for file[7:7]: set if file deleted

0x1 10 Long filename, 1st part0xB 1 0x0F, impossible file attribute used as signature0xC 1 Reserved (?). Set to 0x000xD 1 Checksum for long filename0xE 12 Long filename, 2nd part0x1A 2 First cluster number (always 0x0000 for long filename records)0x1C 4 Long filename, 3rd part



dle. Otherwise, final period is ignored and the string next to final period is used as extension

• If necessary, name part is truncated to a maximum six characters followed by tilde (~) and running sequence number (1, 2, 3, 4…)

• If long filename contains a blank (space, ASCII code 0x20), it is replaced with an underscore (_)

• The short filename characters are converted to upper case.

• If filename has been a valid short name to begin with, it is only converted to upper case without any other modifications

5.3 FAT/VFAT16 caveats

- Even though blank (ASCII code 0x20) is theoretically allowed in short filename, very few appli-cations support it. Thus, it should not be used

- In Windows9x, maximum short name path length is 80 characters. Creation of too deeply nested short name directory structures should be avoided for purposes of compatibility and inter opera-bility

- In Windows9x, maximum length of long filename paths is 260 characters (including terminating NULL). Long filenames can be up to 255 characters (including terminating NULL), but very long names should be avoided since in the worst case they only leave four characters for actual path

- When copying/moving a directory with mixed set of long filenames and short ones, data loss may occur when a file with long name is copied, short name is generated to destination and the source contains a short name which is the same as the generated short name in destination direc-tory

Same volume label should be written both to PBR and root directory (using Label attribute in one of the rootdirectory entries), as per MS Windows behaviour. Maximum label length is 11 characters.

5.4 Example of long filename entries

Files “VeryLongFilename.txt”, “VeryVeryLongFilename.txt” and “Truly very, very long filename.txt” were



created to a floppy, using Windows95. The directory entries were arranged as follows:

Figure 1: Example Of Directory Entry

5.5 Example of file system memory layout

The following chart illustrates the memory layout of file system with a 32MB (62720 sectors) card using sin-gle partition with a file system. At first, the CHS geometry is calculated (S = 32):

So, size of one cylinder is 32kB = 64 sectors. Since the partition is required to be on the cylinder boundaryand there's a 16kB partition table in the very beginning of the media, the total number of logical cylinders inthe partition is CN = 980 –1 = 979. Experimenting with clusters sizes and Equation 4-4 yields a cluster size sc

P 62720= H ceil2 6272032 1024⋅---------------------- 2= = C floor 62720

32 2⋅--------------- 980= =



= 1 (one sector per cluster). Thus, Equations 4-4 and 4-5 produce the following results:

In the following chart, data sectors are set to zero in order to highlight the arrangement of partition and system

sc 1=

hF ceil 32 979 2 257 1 32–⋅+⋅ ⋅4096 1 32+⋅

------------------------------------------------------------- 16= =

dN floor 32 979 2 32 16 32–⋅+⋅ ⋅1

------------------------------------------------------------- 62112= =

sF ceil 621112 2+256

--------------------------- 243= =

r 32 rem 2 243⋅ 32,( )– 32 6– 26= = =



areas:

Figure 2: System Area Layout

System area layout

32

26

243

243

32

0

320

64

128

192

256

320

384

448

512

576

640

sect

ors

Data areaRDE's2nd FAT1st FATReservedGap1Part. table



Appendix A: Abbreviations

aka Also known asCHS Cylinder-Head-Sector. Traditional addressing mode of floppies and hard drives. Their range is C = 0

– 1023, H = 0 – 255, S = 1 – 63FAT File Allocation Table, table of linked-list values in the FAT file system containing allocation informa-

tion. Also generic name for various file system implementations employing FATsFAT16 16 refers to number of bits in a single allocation unit in the FATRDE Root Directory Entry. Located immediately after FAT(s) in the file systemMBR Master Boot Record. Aka Master Boot Sector. Contains partition information and optionally master

boot codePBR Partition Boot Record. Aka Partition Boot Sector. Contains FAT parameters of the partition and

optionally boot codeSPT Sectors Per Track. Aka Sectors Per Head. Parameter S of CHS geometry



Appendix B: References

MultiMediaCard System SpecificationEN ISO 29293:1989Undocumented DOS 2nd edition

Andrew Schulman, Ralf Brown, David Maxey, Raymond J. Michels, Jim KyleAddison-Wesley, 1993

Interrupt List Release 6.0Ralf Brown3. January 1999http://www.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/WWW/files.html

Detailed Explanation of FAT Boot SectorReviewed: October 25, 2000Microsoft Knowledge Base, Article ID: Q140418

Default Cluster Size for FAT and NTFSReviewed: March 1, 2000Microsoft Knowledge Base, Article ID: Q140365

How Windows Generates 8.3 File Names from Long File NamesReviewed: December 14, 2000Microsoft Knowledge Base, Article ID: Q142982

Copying Files with Mix of LFN and SFN May Lead to Data LossLast reviewed: March 1, 2000Microsoft Knowledge Base, Article ID: Q195144


MMCA FAT16 File System Specification -...

Documents

Transcript of MMCA FAT16 File System Specification -...