Threadx-docs/rtos-docs/filex/chapter3.md

title, description

title	description
Chapter 3 - Functional components of FileX	This chapter contains a description of the high-performance FileX embedded file system from a functional perspective.

Chapter 3 - Functional components of FileX

This chapter contains a description of the high-performance FileX embedded file system from a functional perspective.

Media Description

FileX is a high-performance embedded file system that conforms to the FAT file system format. FileX views the physical media as an array of logical sectors. How these sectors are mapped to the underlying physical media is determined by the I/O driver connected to the FileX media during the fx_media_open call.

FAT12/16/32 Logical Sectors

The exact organization of the media's logical sectors is determined by the contents of the physical media's boot record. The general layout of the media's logical sectors is shown in Figure 1.

FileX logical sectors start at logical sector 1, which points to the first reserved sector of the media. Reserved sectors are optional, but when in use they typically contain system information such as boot code.

FAT12/16/32 Media Boot Record

The exact sector offset of the other areas in the logical sector view of the media is derived from the contents of the media boot record. The location of the boot record is typically at sector 0. However, if the media has hidden sectors, the offset to the boot sector must account for them (they are located immediately BEFORE the boot sector). Table 1 lists the media's boot record components, and the components are described in the paragraphs.

• Jump Instruction The jump instruction field is a three-byte field that represents an Intel x86 machine instruction for a processor jump. This is a legacy field in most situations.

  

  FIGURE 1. FileX Media Logical Sector View

• OEM Name The OEM name field is reserved for manufacturers to place their name or a name for the device.

• Bytes Per Sector The bytes per sector field in the media boot record defines how many bytes are in each sector—the fundamental element of the media.

• Sectors Per Cluster The sectors per cluster field in the media boot record defines the number of sectors assigned to a cluster. The cluster is the fundamental allocation element in an FAT compatible file system. All file information and subdirectories are allocated from the media's available clusters as determined by the File Allocation Table (FAT).

  TABLE 1. FileX Media Boot Record

  Offset	Field	Number of Bytes
  0x00	Jump Instruction (e9,xx,xx or eb,xx,90)	3
  0x03	OEM Name	8
  0x0B	Bytes Per Sector	2
  0x0D	Sectors Per Cluster	1
  0x0E	Number of Reserved Sectors	2
  0x10	Number of FATs	1
  0x11	Size of Root Directory	2
  0x13	Number of Sectors FAT-12 & FAT-16	2
  0x15	Media Type	1
  0x16	Number of Sectors Per FAT	2
  0x18	Sectors Per Track	2
  0x1A	Number of Heads	2
  0x1C	Number of Hidden Sectors	4
  0x20	Number of Sectors - FAT-32	4
  0x24	Sectors per FAT (FAT-32)	4
  0x2C	Root Directory Cluster	4
  0x3E	System Boot code	448
  0x1FE	0x55AA	2

• Reserved Sectors The reserved sectors field in the media boot record defines the number of sectors reserved between the boot record and the first sector of the FAT area. This entry is zero in most cases.

• Number of FATs The number of FATs entry in the media boot record defines the number of FATs in the media. There must always be at least one FAT in a media. Additional FATs are merely duplicate copies of the primary (first) FAT and are typically used by diagnostic or recovery software.

• Root Directory Size The root directory size entry in the media boot record defines the fixed number of entries in the root directory of the media. This field is not applicable to subdirectories and the FAT-32 root directory because they are both allocated from the media's clusters.

• Number of Sectors FAT-12 & FAT-16 The number of sectors field in the media boot record contains the total number of sectors in the media. If this field is zero, then the total number of sectors is contained in the number of sectors FAT-32 field located later in the boot record.

• Media Type The media type field is used to identify the type of media present to the device driver. This is a legacy field.

• Sectors Per FAT The sectors per FAT filed in the media boot record contains the number of sectors associated with each FAT in the FAT area. The number of FAT sectors must be large enough to account for the maximum possible number of clusters that can be allocated in the media.

• Sectors Per Track The sectors per track field in the media boot record defines the number of sectors per track. This is typically only pertinent to actual disk-type media. FLASH devices don't use this mapping.

• Number of Heads The number of heads field in the media boot record defines the number of heads in the media. This is typically only pertinent to actual disk-type media. FLASH devices don't use this mapping.

• Hidden Sectors The hidden sectors field in the media boot record defines the number of sectors before the boot record. This field is maintained in the FX_MEDIA control block and must be accounted for in FileX I/O drivers in all read and write requests made by FileX.

• Number of Sectors FAT-32 The number of sectors field in the media boot record is valid only if the two-byte number of sectors field is zero. In such a case, this four-byte field contains the number of sectors in the media.

• Sectors per FAT (FAT-32) The sectors per FAT (FAT-32) field is valid only in FAT-32 format and contains the number of sectors allocated for each FAT of the media.

• Root Directory Cluster The root directory cluster field is valid only in FAT-32 format and contains the starting cluster number of the root directory.

• System Boot Code The system boot code field is an area to store a small portion of boot code. In most devices today, this is a legacy field.

• Signature 0x55AA The signature field is a data pattern used to identify the boot record. If this field is not present, the boot record is not valid.

exFAT

The maximum file size in FAT32 is 4GB, which limits the wide adoption of high-definition multimedia files. By default FAT32 supports storage media up to 32GB. With increasing flash and SD card capacity, FAT32 becomes less efficient in managing large volumes. exFAT is designed to overcome these limitations. exFAT supports file size up to one Exabyte (EB), which is approximately one billion GB. Another significant difference between exFAT and FAT32 is that exFAT uses bitmap to manage available space in the volume, making exFAT more efficient in finding available space when writing data to the file. For file stored in contiguous clusters, exFAT eliminates the walking down the FAT chain to find all the clusters, making it more efficient when accessing large files. exFAT is required for flash storage and SD cards larger than 32GB.

exFAT Logical Sectors

The general layout of the media's logical sectors in exFAT is illustrated in Figure 2. In exFAT the boot block and the FAT area belong to System Area. The rest of the clusters are User Area. Although not required, exFAT standard does recommend that the Allocation Bitmap is at the beginning of the User Area, followed by the Up-case Table and the root directory.

exFAT Media Boot Record

The content of the Media Boot Record in exFAT is different from those in FAT12/16/32. They are listed in Table 2. To prevent confusion, the area between 0x0B and 0x40, which contains various media parameters in FAT12/16/32 is marked as Reserved in exFAT. This reserved area must be programmed with zeros, avoiding any misinterpreting the Media Boot Record.

FIGURE 2. exFAT Logical Sectors

• Jump Instruction The jump instruction field is a three-byte field that represents an Intel x86 machine instruction for a processor jump. This is a legacy field in most situations.

  TABLE 2. exFAT Media Boot Record

  Offset	Field	Number of Bytes
  0x00	Jump Instruction	3
  0x03	File System Name	8
  0x0B	Reserved	53
  0x40	Partition Offset	8
  0x48	Volume Length	8
  0x50	FAT Offset	4
  0x54	FAT Length	4
  0x58	Cluster Heap Offset	4
  0x5C	Cluster Count	4
  0x60	First Cluster of Root Directory	4
  0x64	Volume Serial Number	4
  0x68	File System Revision	2
  0x6A	Volume Flags	2
  0x6C	Bytes Per Sector Shift	1
  0x6D	Sector Per Cluster Shift	1
  0x6E	Number of FATs	1
  0x6F	Drive Select	1
  0x70	Percent in Use	7
  0x71	Reserved	1
  0x78	Boot Code	390
  0x1FE	Boot Signature	2

• File System Name For exFAT the file system name field must be "EXFAT" followed by three trailing white spaces.

• Reserved The content of the reserved field must be zero. This region overlaps with the boot records in FAT12/16/ 32. Making this area zero avoids file systems from mis-interprets this volume.

• Partition Offset The partition offset field indicates the starting of this partition.

• Volume Length The volume length field defines the size, in number of sectors, of this partition.

• FAT Offset The FAT offset field defines the starting sector number, relative to the beginning of this partition, of the FAT table for this partition.

• FAT Length The FAT length field defines the size of the FAT table, in number of sectors.

• Cluster Heap Offset The cluster heap offset field defines the starting sector number, relative to the beginning of the partition, of the cluster heap. Cluster heap is the area where the directories information and the file data are stored.

• Cluster Count The cluster count field defines the number of cluster this partition has.

• First Cluster of Root Directory The first cluster of root directory field defines the starting location of the root directory, which is recommend to be right after the allocation bitmap and the up-case table.

• Volume Serial Number The volume serial number field defines the serial number for this partition.

• File System Revision The file system revision field defines the major and minor version of exFAT.

• Volume Flags The volume flags field contains flags indicating the state of this volume.

• Bytes Per Sector Shift The bytes per sector shift field defines the number of bytes per sector, in log2(n), where n is the number of bytes per sector. For example, in SD card, sector size is 512 bytes. Therefore this field shall be 9 (log2(512) = 9).

• Sectors Per Cluster Shift The sectors per cluster shift field defines the number of sectors in a cluster, in log2(n) where n is the number of sectors per cluster.

• Number of FATs The number of FATs field defines the number of FAT tables in this partition. For exFAT, the value is recommended to be 1, for one FAT table.

• Drive Select The driver select field defines the extended INT 13h drive number.

• Percent in Use The percent in use field define the percentage of the clusters in the cluster heap is being allocated. The valid values are between 0 and 100, inclusive.

• Reserved This field is reserved for future use.

• Boot Code The boot code field is an area to store a small portion of the boot code. In most devices today, this is a legacy field.

• Signature 0x55AA The boot signature field is a data pattern used to identify the boot record. If this field is not present, the boot record is not valid.

File Allocation Table (FAT)

The File Allocation Table (FAT) starts after the reserved sectors in the media. The FAT area is basically an array of 12-bit, 16-bit, or 32-bit entries that determine if that cluster is allocated or part of a chain of clusters comprising a subdirectory or a file. The size of each FAT entry is determined by the number of clusters that need to be represented. If the number of clusters (derived from the total sectors divided by the sectors per cluster) is less than or equal to 4,086, 12-bit FAT entries are used. If the total number of clusters is greater than 4,086 and less than 65,525, 16-bit FAT entries are used. Otherwise, if the total number of clusters is greater than or equal to 65,525, 32-bit FAT or exFAT are used.

For FAT12/16/32, the FAT table not only maintains the cluster chain, it also provides information on cluster allocation: whether or not a cluster is available. In exFAT, the cluster allocation information is maintained by an Allocation Bitmap Directory Entry. Each partition has its own allocation bitmap. The size of the bitmap is large enough to cover all the available clusters. If a cluster is available for allocation, the corresponding bit in the allocation bitmap is set to 0. Otherwise the bit is set to 1. For a file that occupies consecutive clusters, exFAT does not require a FAT chain to keep track of all the clusters. However, for a file that does not occupy consecutive clusters, a FAT chain still needs to be maintained.

FAT Entry Contents

The first two entries in the FAT table are not used and typically have the following contents.

FAT Entry	12-bit FAT	16-bit FAT	32-bit FAT	exFAT
Entry 0	0x0F0	0x00F0	0x000000F0	0xF8FFFFFF
Entry 1	0xFFF	0xFFFF	0x0FFFFFFF	0xFFFFFFFF

FAT entry number 2 represents the first cluster in the media's data area. The contents of each cluster entry determines whether or not it is free or part of a linked list of clusters allocated for a file or a subdirectory. If the cluster entry contains another valid cluster entry, then the cluster is allocated and its value points to the next cluster allocated in the cluster chain.

Possible cluster entries are defined as follows.

Meaning	12-bit FAT	16-bit FAT	32-bit FAT	exFAT
Free Cluster	0x000	0x0000	0x00000000	0x00000000
Not Used	0x001	0x0001	0x00000001	0x00000001
Reserved	0xFF0-FF6	0xFFF0-FFF6	0x0FFFFFF0-6	ClusterCounter +2 to 0xFFFFFFF6
Bad Cluster	0xFF7	0xFFF7	0x0FFFFFF7	0xFFFFFFF7
Reserved	-	-	-	0xFFFFFFF8-E
Last Cluster	0xFF8-FFF	0xFFF8-FFFF	0x0FFFFFF8-F	0xFFFFFFFF
Cluster Link	0x002-0xFEF	0x0002-FFEF	0x2-0x0FFFFFEF	0x2 - ClusterCount + 1

The last cluster in an allocated chain of clusters contains the Last Cluster value (defined above). The first cluster number is found in the file or subdirectory's directory entry.

Internal Logical Cache

FileX maintains a most-recently-used logical sector cache for each opened media. The maximum size of the logical sector cache is defined by the constant FX_MAX_SECTOR_CACHE and is located in fx_api.h. This is the first factor determining the size of the internal logical sector cache.

The other factor that determines the size of the logical sector cache is the amount of memory supplied to the fx_media_open call by the application. There must be enough memory for at least one logical sector. If more than FX_MAX_SECTOR_CACHE logical sectors are required, the constant must be changed in fx_api.h and the entire FileX library must be rebuilt.

Important: Each opened media in FileX may have a different cache size depending on the memory supplied during the open call.

Write Protect

FileX provides the application driver the ability to dynamically set write protection on the media. If write protection is required, the driver sets to FX_TRUE the fx_media_driver_write_protect field in the associated FX_MEDIA structure. When set, all attempts by the application to modify the media are rejected as well as attempts to open files for writing. The driver may also disable write protection by clearing this field.

Free Sector Update

FileX provides a mechanism to inform the application driver when sectors are no longer in use. This is especially useful for FLASH memory managers that manage all logical sectors being used by FileX.

If notification of free sectors is required, the application driver sets to FX_TRUE the fx_media_driver_free_sector_update field in the associated FX_MEDIA structure. This assignment is typically done during driver initialization.

Setting this field, FileX makes a FX_DRIVER_RELEASE_SECTORS driver call indicating when one or more consecutive sectors become free.

Media Control Block FX_MEDIA

The characteristics of each open media in FileX are contained in the media control block. This structure is defined in the file fx_api.h.

The media control block can be located anywhere in memory, but it is most common to make the control block a global structure by defining it outside the scope of any function.

Locating the control block in other areas requires a bit more care, just like all dynamically allocated memory. If a control block is allocated within a C function, the memory associated with it is part of the calling thread's stack.

Warning

In general, avoid using local storage for control blocks because after the function returns, all of its local variable stack space is released—regardless of whether it is still in use!

FAT12/16/32 Directory Description

FileX supports both 8.3 and Windows Long File Name (LFN) name formats. In addition to the name, each directory entry contains the entry's attributes, the last modified time and date, the starting cluster index, and the size in bytes of the entry. Table 3 shows the contents and size of a FileX 8.3 directory entry.

• Directory Name

  FileX supports file names ranging in size from 1 to 255 characters. Standard eight-character file names are represented in a single directory entry on the media. They are left justified in the directory name field and are blank padded. In addition, the ASCII characters that comprise the name are always capitalized.

  Long File Names (LFNs) are represented by consecutive directory entries, in reverse order, followed immediately by an 8.3 standard file name. The created 8.3 name contains all the meaningful directory information associated with the name. Table 4 shows the contents of the directory entries used to hold the Long File Name information, and Table 5 shows an example of a 39-character LFN that requires a total of four directory entries.

  Important: The constant FX_MAX_LONG_NAME_LEN, defined in fx_api.h, contains the maximum length supported by FileX.

• Directory Filename Extension

  For standard 8.3 file names, FileX also supports the optional three-character directory filename extension. Just like the eight-character file name, filename extensions are left justified in the directory filename extension field, blank padded, and always capitalized.

  TABLE 3. FileX 8.3 Directory Entry

  Offset	Field	Number of Bytes
  0x00	Directory Entry Name	8
  0x08	Directory Extension	3
  0x0B	Attributes	1
  0x0C	NT (introduced by the long file name format and is reserved for NT [always 0])	1
  0x0D	Created Time in milliseconds ( introduced by the long file name format and represents the number of milliseconds when the file was created.)	1
  0x0E	Created Time in hours & minutes (introduced by the long file name format and represents the hour and minute the file was created )	2
  0x10	Created Date (introduced by the long file name format and represents the date the file was created.)	2
  0x12	Last Accessed Date ( introduced by the long file name format and represents the date the file was last accessed.)	2
  0x14	Starting Cluster (Upper 16 bits FAT-32 only)	2
  0x16	Modified Time	2
  0x18	Modified Date	2
  0x1A	Starting Cluster (Lower 16 bits FAT-32 or FAT-12 or FAT-16)	2
  0x1C	File Size	4

• Directory Attributes

  The one-byte directory attribute field entry contains a series of bits that specify various properties of the directory entry. Directory attribute definitions are as follow:

  Attribute Bit	Meaning
  0x01	Entry is read-only.
  0x02	Entry is hidden.
  0x04	Entry is a system entry.
  0x08	Entry is a volume label
  0x10	Entry is a directory.
  0x20	Entry has been modified.

  Because all the attribute bits are mutually exclusive, there may be more than one attribute bit set at a time.

• Directory Time

  The two-byte directory time field contains the hours, minutes, and seconds of the last change to the specified directory entry. Bits 15 through 11 contain the hours, bits 10 though 5 contain the minutes, and bits 4 though 0 contain the half seconds. Actual seconds are divided by two before being written into this field.

• Directory Date

  The two-byte directory date field contains the year (offset from 1980), month, and day of the last change to the specified directory entry. Bits 15 through 9 contain the year offset, bits 8 through 5 contain the month offset, and bits 4 through 0 contain the day.

• Directory Starting Cluster

  This field occupies 2 bytes for FAT-12 and FAT-16. For FAT-32 this field occupies 4 bytes. This field contains the first cluster number allocated to the entry (subdirectory or file).

  Note: *Note that FileX creates new files without an initial cluster (starting cluster field equal to zero) to allow users to optionally allocate a contiguous number of clusters for a newly created file. *

• Directory File Size

  The four-byte directory file size field contains the number of bytes in the file. If the entry is really a subdirectory, the size field is zero.

Long File Name Directory

• Ordinal

  The one-byte ordinal field that specifies the number of the LFN entry. Because LFN entries are positioned in reverse order, the ordinal values of the LFN directory entries comprising a single LFN decrease by one. In addition, the ordinal value of the LFN directly before the 8.3 file name must be one.

  TABLE 4. Long File Name Directory Entry

  Offset	Field	Number of Bytes
  0x00	Ordinal Field	1
  0x01	Unicode Character 1	2
  0x03	Unicode Character 2	2
  0x05	Unicode Character 3	2
  0x07	Unicode Character 4	2
  0x09	Unicode Character 5	2
  0x0B	LFN Attributes	1
  0x0C	LFN Type (Reserved always 0)	1
  0x0D	LFN Checksum	1
  0x0E	Unicode Character 6	2
  0x10	Unicode Character 7	2
  0x12	Unicode Character 8	2
  0x14	Unicode Character 9	2
  0x16	Unicode Character 10	2
  0x18	Unicode Character 11	2
  0x1A	LFN Cluster (unused always 0)	2
  0x1C	Unicode Character 12	2
  0x1E	Unicode Character 13	2

• Unicode Character

  The two-byte Unicode Character fields are designed to support characters from many different languages. Standard ASCII characters are represented with the ASCII character stored in the first byte of the Unicode character followed by a space character.

• LFN Attributes

  The one-byte LFN Attributes field contains attributes that identify the directory entry as an LFN directory entry. This is accomplished by having the read-only, system, hidden, and volume attributes all set.

• LFN Type

  The one-byte LFN Type field is reserved and is always 0.

• LFN Checksum

  The one-byte LFN Checksum field represents a checksum of the 11 characters of the associated MSDOS 8.3 file name. This checksum is stored in each LFN entry to help ensure the LFN entry corresponds to the appropriate 8.3 file name.

• LFN Cluster

  The two-byte LFN Cluster field is unused and is always 0.

  TABLE 5. Directory Entries Comprising a 39-Character LFN

  Entry	Meaning
  1	LFN Directory Entry 3
  2	LFN Directory Entry 2
  3	LFN Directory Entry 1
  4	8.3 Directory Entry (ttttt~n.xx)

exFAT Directory Description

exFAT file system stores directory entry and file name differently. Directory entry contains the entry's attributes, various timestamps on when the entry was created, modified, and accessed. Other information, such as file size and starting cluster, is stored in Stream Extension Directory Entry which immediately follows the primary directory entry. exFAT supports only Long File Name (LFN) name format. which is stored in File Name Directory Entry immediately follows the Stream Extension Directory Entry, as shown in Table 2.

exFAT File Directory Entry

A description of exFAT file directory entry and its contents is included in the following table and paragraphs.

• Entry Type

  The entry type field indicates the type of this entry. For File Directory Entry, this field must be 0x85.

• Secondary Entry Count

  The secondary entry count field indicates the number of secondary entries immediately follows this primary entry. Secondary entries associated with the file directory entry include one stream extension directory entry and one or more file name directory entries.

  TABLE 6. exFAT File Directory Entry

  Offset	Field	Number of Bytes
  0x00	Entry Type	1
  0x01	Secondary Entry	1
  0x02	Checksum	2
  0x04	File Attributes	2
  0x06	Reserved 1	2
  0x08	Create Timestamp	4
  0x0C	Last Modified Timestamp	4
  0x10	Last Accessed Timestamp	4
  0x14	Create 10ms Increment	1
  0x15	Last Modified 10ms Increment	1
  0x16	Create UTC Offset	1
  0x17	Last Modified UTC Offset	1
  0x18	Last Access UTC Offset	1
  0x19	Reserved 2	7

• Checksum

  The checksum field contains the value of the checksum over all entries in the directory entry set (the file directory entry and its secondary entries).

• File Attributes

  The one-byte attributes field entry contains a series of bits that specify various properties of the directory entry. The definition of most attributes bits is identical to FAT 12/16/32. Directory attribute definitions are as follows:

  Attribute Bit	Meaning
  0x01	Entry is read-only
  0x02	Entry is hidden
  0x04	Entry is a system entry
  0x08	Entry is reserved
  0x10	Entry is a directory
  0x20	Entry has been modified
  All other bits	Reserved

• Reserved1

  This field should be zero.

• Create Timestamp

  The create timestamp field, combining information from the create 10ms Increment field, describes the local date and time the file or the directory was created.

• Last Modified Timestamp

  The last modified timestamp field, combining information from the last modified 10ms increment field, describe the local date and time the file or the directory was last modified. See notes below on timestamps.

• Last Accessed Timestamp

  The last accessed timestamp field describes the local date and time the file or the directory was last accessed. See notes below on timestamps.

• Create 10ms Increment

  The create 10ms increment field, combining information from the create timestamp field, describes the local date and time the file or the directory was created. See notes below on timestamps.

• Last Modified 10ms Increment

  The last modified 10ms increment field, combining information from the last modified timestamp field, describe the local date and time the file or the directory was last modified. See notes below on timestamps.

• Create UTC Offset

  The create UTC offset field describes the difference between the local time and the UTC time, when the file or the directory was created. See notes below on timestamps.

• Last Modified UTC Offset

  The last modified UTC offset field describes the difference between the local time and the UTC time, when the file or the directory was last modified. See notes below on timestamps.

• Last Accessed UTC Offset

  The last accessed UTC offset field describes the difference between the local time and the UTC time, when the file or the directory was last accessed. See notes below on timestamps.

• Reserved2

  This field should be zero.

Notes on Timestamps

• Timestamp Entry The timestamp fields are interpreted as follows:

• 10ms Increment Fields The value in the 10ms increment field provides finer granularity to the timestamp value. The valid values are between 0 (0ms) and 199 (1990ms).

  

• UTC Offset Field

  

• Offset Value

  7-bit signed integer represents offset from UTC time, in 15 minutes increments.

• Valid

  Whether or not the value in the offset field is valid. 0 indicates the value in the offset value field is invalid. 1 indicates the value is valid.

Stream Extension Directory Entry

A description of Stream Extension Directory Entry and its contents is included in the following table.

TABLE 7. Stream Extension Directory Entry

Offset	Field	Number of Bytes
0x00	Entry Type	1
0x01	Flags	1
0x02	Reserved 1	1
0x03	Name Length	1
0x04	Name Hash	2
0x06	Reserved 2	2
0x08	Valid Data Length	8
0x10	Reserved 3	4
0x14	First Cluster	4
0x18	Data Length	8

• Entry Type

  The entry type field indicates the type of this entry. For streaming extension Directory Entry, this field must be 0xC0.

• Flags

  This field contains a series of bits that specify various properties:

  Flag Bit	Meaning
  0x01	This field indicates whether or not allocation of clusters is possible. This field should be 1.
  0x02	This field indicates whether or not the associated clusters are contiguous. A value 0 means the FAT entry is valid and FileX shall follow the FAT chain. A value 1 means the FAT entry is invalid and the clusters are contiguous.
  All other bits	Reserved.

• Reserved 1

  This field should be 0.

• Name Length

  The name length field contains the length of the unicode string in the file name directory entries collectively contain. The file name directory entries shall immediately follow this stream extension directory entry.

• Name Hash

  The name hash field is a 2-byte entry, containing the hash value of the up-cased file name. The hash value allows faster file/directory name lookup: if the hash values don't match, the file name associated with this entry is not a match.

• Reserved 2

  This field should be 0.

• Valid Data Length

  The valid data length field indicates the amount of valid data in the file.

• Reserved 3

  This filed should be 0.

• First Cluster

  The first cluster field contains index of the first cluster of the data stream.

• Data Length

  The data length field contains the total number of bytes in the allocated clusters. This value may be larger than Valid Data Length, since exFAT allows pre-allocation of data clusters.

Root Directory

In FAT 12- and 16-bit formats, the root directory is located immediately after all the FAT sectors in the media and can be located by examining the fx_media_root_sector_start in an opened FX_MEDIA control block. The size of the root directory, in terms of number of directory entries (each 32 bytes in size), is determined by the corresponding entry in the media's boot record.

The root directory in FAT-32 and exFAT can be located anywhere in the available clusters. Its location and size are determined from the boot record when the media is opened. After the media is opened, the fx_media_root_sector_start field can be used to find the starting cluster of the FAT-32 or exFAT root directory.

Subdirectories

There is any number of subdirectories in an FAT system. The name of the subdirectory resides in a directory entry just like a file name. However, the directory attribute specification (0x10) is set to indicate the entry is a subdirectory and the file size is always zero. Figure 3 shows what a typical subdirectory structure looks like for a new singlecluster subdirectory named SAMPLE.DIR with one file called FILE.TXT. In most ways, subdirectories are very similar to file entries. The first cluster field points to the first cluster of a linked list of clusters. When a subdirectory is created, the first two directory entries contain default directories, namely the "." directory and the ".." directory. The "." directory points to the subdirectory itself, while the ".." directory points to the previous or parent directory.

Global Default Path

FileX provides a global default path for the media. The default path is used in any file or directory service that does not explicitly specify a full path.

Initially, the global default directory is set to the media's root directory. This may be changed by the application by calling fx_directory_default_set.

The current default path for the media may be examined by calling fx_directory_default_get. This routine provides a string pointer to the default path string maintained inside of the FX_MEDIA control block.

Local Default Path

FileX also provides a thread-specific default path that allows different threads to have unique paths without conflict. The FX_LOCAL_PATH structure is supplied by the application during calls to fx_directory_local_path_set and fx_directory_local_path_restore to modify the local path for the calling thread.

If a local path is present, the local path takes precedence over the global default media path. If the local path is not setup or if it is cleared with the fx_directory_local_path_clear service, the media's global default path is used once again.

File Description

FileX supports standard 8.3 character and long file names with three-character extensions. In addition to the ASCII name, each file entry contains the entry's attributes, the last modified time and date, the starting cluster index, and the size in bytes of the entry.

File Allocation

FileX supports the standard cluster allocation scheme of the FAT format. In addition, FileX supports pre-cluster allocation of contiguous clusters. To accommodate this, each FileX file is created with no allocated clusters. Clusters are allocated on subsequent write requests or on fx_file_allocate requests to pre-allocate contiguous clusters.

Figure 4, "FileX FAT-16 File Example," shows a file named FILE.TXT with two sequential clusters allocated starting at cluster 101, a size of 26, and the alphabet as the data in the file's first data cluster number 101.

File Access

A FileX file may be opened multiple times simultaneously for read access. However, a file can only be opened once for writing. The information used to support the file access is contained in the FX_FILE file control block.

Note: Note that the media driver can dynamically set write protection. If this happens all write requests are rejected as well as attempts to open a file for writing.

File Layout in exFAT

The design of exFAT does not require FAT chain to be maintained for a file if data is stored in contagious clusters. The NoFATChain bit in the Stream Extension Directory Entry indicates whether or not the FAT chain should be used when reading data from the file. If the NoFATChain is set, FileX reads sequentially from the cluster indicated in the First Cluster field in the Stream Extension Directory Entry.

On the other hand, if the NoFATChain is clear, FileX will follow the FAT chain in order to traverse the entire file, similar to the FAT chain in FAT12/16/32.

Figure 3 shows two sample files, one does not require FAT chain, and the other one requires a FAT chain.

System Information

FileX system information consists of keeping track of the open media instances and maintaining the global system time and date.

FIGURE 3. File with Contiguous Clusters vs. File Requiring FAT Link

By default, the system date and time are set to the last release date of FileX. To have accurate system date and time, the application must call fx_system_time_set and fx_system_date_set during initialization.

System Date

The FileX system date is maintained in the global _fx_system_date variable. Bits 15 through 9 contain the year offset from 1980, bits 8 through 5 contain the month offset, and bits 4 through 0 contain the day. |

System Time

The FileX system time is maintained in the global _fx_system_time variable. Bits 15 through 11 contain the hours, bits 10 though 5 contain the minutes, and bits 4 though 0 contain the half seconds.

Periodic Time Update

During system initialization, FileX creates a ThreadX application timer to periodically update the system date and time. The rate at which the system date and time update is determined by two constants used by the _fx_system_initialize function.

The constants FX_UPDATE_RATE_IN_SECONDS and FX_UPDATE_RATE_IN_TICKS represent the same period of time. The constant FX_UPDATE_RATE_IN_TICKS is the number of ThreadX timer ticks that represents the number of seconds specified by the constant FX_UPDATE_RATE_IN_SECONDS. The FX_UPDATE_RATE_IN_SECONDS constant specifies how many seconds between each FileX time update. Therefore, the internal FileX time increments in intervals of FX_UPDATE_RATE_IN_SECONDS. These constants may be supplied during compilation of fx_system_initialize, or the developer may modify the defaults found in the fx_port.h file of the FileX release.

The periodic FileX timer is used only for updating the global system date and time, which is used solely for file time-stamping. If time-stamping is not necessary, simply define FX_NO_TIMER when compiling fx_system_initialize.c to eliminate the creation of the FileX periodic timer.

FIGURE 4. FileX FAT-16 File Example