Format of the Path Names

The format of path name on the FatFs module is similer to the filename specs of DOS/Windos as follows:

[drive#:][/]directory/file

The FatFs module supports long file name (LFN) and 8.3 format file name (SFN). The LFN can be used when FF_USE_LFN >= 1. The sub directories are separated with a \ or / in the same way as DOS/Windows API. Duplicated separators are skipped and ignored. Only a difference is that the heading drive prefix to specify logical drive is in a numeral + colon. When drive prefix is omitted, the drive number is assumed as default drive (drive 0 or current drive).

Control characters (\0 to \x1F) are recognized as end of the path name. Leading/embedded white spaces in the path name are valid as a part of the name at LFN configuration but the white space is recognized as end of the path name at non-LFN configuration. Trailing white spaces and dots are ignored at both configurations.

In default configuration (FF_FS_RPATH == 0), it does not have a concept of current directory like OS oriented filesystem. Every object on the volume is always specified in full path name that followed from the root directory. Dot directory names (".", "..") are not allowed. Heading separator is ignored and it can be exist or omitted. The default drive is fixed to drive 0.

When relative path is enabled (FF_FS_RPATH >= 1), specified path is followed from the root directory if a heading separator is exist. If not, it is followed from the current directory of the drive set by f_chdir function. Dot names are also allowed for the path names. The default drive is the current drive set by f_chdrive function.

The FatFs module supports long file name (LFN) and 8.3 format file name (SFN). The LFN can be used when FF_USE_LFN >= 1. The sub-directories are separated with a \ or / as the same way as DOS/Windows API. Duplicated separator and terminating separator, such as "//animal///cat/", are ignored. Only a difference is that the heading drive prefix to specify the logical drive, an FAT volume, is in a digit (0-9) + a colon, while it is in an alphabet (A-Z) + a colon in DOS/Windows. The logical drive number is the identifier to specify the volume to be accessed. When drive prefix is omitted, the logical drive number is assumed as default drive.

Control characters (\0 to \x1F) are recognized as end of the path name. In LFN configuration, leading or embedded white spaces in the file name are valid as part of the file name, but the treminating white space and dot of the file name are ignored and truncated. In non-LFN configuration, white space is recognized as end of the path name.

In default configuration (FF_FS_RPATH == 0), it does not have a concept of current directory like OS oriented filesystem. Every object on the volume is always specified in full path name followed from the root directory. Dot directory names (".", "..") are not allowed. Heading separator is ignored and it can be exist or omitted. The default drive is fixed to drive 0.

When relative path feature is enabled (FF_FS_RPATH >= 1), specified path is followed from the root directory if a heading separator is exist. If not, it is followed from the current directory of the default drive. Dot directory name is also allowed for the path name. The current directory is set by f_chdir function and the default drive is the current drive set by f_chdrive function.

@@ -35,51 +35,57 @@

Path name	FF_FS_RPATH == 0	FF_FS_RPATH >= 1
file.txt	A file in the root directory of the drive 0	A file in the current directory of the current drive
dir1/..	Invalid name	The current directory
/..	Invalid name	The root directory (sticks the top level)

Also the drive prefix can be in pre-defined arbitrary string. When the option FF_STR_VOLUME_ID == 1, also arbitrary string volume ID can be used as drive prefix. e.g. "flash:file1.txt", "ram:temp.dat" or "usb:". When FF_STR_VOLUME_ID == 2, Unix style drive prefix can be used. e.g. "/flash/file1.txt", "/ram/temp.dat" or "/usb". However, it cannot traverse the drives such as "/flash/../ram/temp.dat". The Unix style drive prefix may lead a confusion in identification between volume ID and file name. For instance, which does "/flash" mean, a file "flash" on the root directory without drive prefix or a drive prefix of "flash"? If the string following a heading slash matches with any volume ID, it is treated as a drive prefix and skipped over.

- +

When FF_STR_VOLUME_ID == 2, Unix style drive prefix can be used. e.g. "/flash/file1.txt", "/ram/temp.dat" or "/sd". If a heading separator is exist, it is treated as start of drive prefix and in absolute path. Any form as "root directory in current drive" and "current directory in specified drive" cannot be used. Double dot name cannot traverse the drives such as "/flash/../ram/foo.dat".

Remark: In this revision, double dot name ".." cannot follow the parent directory on the exFAT volume. It will work as "." and stay there.

Legal Characters and Case Sensitivity

On the FAT filesystem, legal characters for object name (file/directory name) are, 0-9 A-Z ! # $ % & ' ( ) - @ ^ _ ` { } ~ and extended characters (\x80-\xFF). Under LFN supported system, also + , ; = [ ] and white space are legal for the object name and the white spaces and dots can be placed anywhere in the path name except for end of the object name.

FAT filesystem is case-insensitive to the object names on the volume. Object name on the FAT volume is compared in case-insensitive. For instance, these three names, file.txt, File.Txt and FILE.TXT, are identical. This is applied to extended charactres as well. When an object is created on the FAT volume, up converted name is recorded to the SFN entry, and the raw name is recorded to the LFN entry when LFN function is enabled.

As for the MS-DOS and PC DOS for CJK, it was case-sensitive to the DBCS extended characters. To follow this specification, FatFs works with case-sensitive to the extended characters at only non-LFN with DBCS configuration (DOS/DBCS specs). But at LFN configuration, FatFs works with case-insensitive to the extended character (WindowsNT specs). This can cause a problem on compatibility with Windows system when an object with extended characters is created on the volume at non-LFN and DBCS configuration; therfore the object names with DBCS extended characters should not be used on the FAT volume shared by those systems.

In the generic FAT filesystems, the legal characters for object name (file/directory name) are, 0-9 A-Z ! # $ % & ' ( ) - @ ^ _ ` { } ~ in ASCII and extended characters \x80 to \xFF. In the FAT filesystems with LFN extention, also + , ; = [ ], white space and extended characters U+000080 to U+10FFFF are legal for the object name. White spaces and dots can be placed anywhere in the path name except end of the name. Trailing white spaces and dots are ignored.

FAT filesystem is case-insensitive to the object names on the volume. Object name on the FAT volume is compared in case-insensitive. For instance, these three names, file.txt, File.Txt and FILE.TXT, are identical on the FAT filesystem. This is applied to extended charactres as well. When an object is created on the FAT volume, up converted name is recorded to the SFN entry, and the raw name is recorded to the LFN entry when LFN extension is exist.

As for the MS-DOS and PC DOS for CJK (DOS/DBCS), extended characters ware recorded to the SFN entry without up-case conversion and compared in case-sensitive. This causes a problem on compatibility with Windows system when the object with extended characters is created on the volume by DOS/DBCS system; therfore the object names with DBCS extended characters should not be used on the FAT volume shared by those systems. FatFs works with case-sensitive to the extended characters in only non-LFN with DBCS configuration (DOS/DBCS specs). However, FatFs works with case-insensitive to the extended character (WindowsNT specs) in LFN configuration.

Unicode API

The path names are input/output in either ANSI/OEM code or Unicode depends on the configuration options. The type of arguments which specifies the path names is defined as TCHAR. It is an alias of char by default and the code set used for the path name string is ANSI/OEM specifid by FF_CODE_PAGE. When FF_LFN_UNICODE is set to 1, the type of the TCHAR is switched to WCHAR to support UTF-16 encoded Unicode string. When UTF-16 or UTF-8 is specified by this option, the full-featured LFN specification is supported and the Unicode specific characters, such as ââªâ¡â¸â, can also be used for the path name. It also affects data types and encoding of the string I/O functions. To define literal strings, _T(s) and _TEXT(s) macro are available to select either ANSI/OEM or Unicode automatically. The code shown below is an example to define the literal strings.

The path names are input/output in either ANSI/OEM code or Unicode depends on the configuration options. The type of arguments which specifies the path names is defined as TCHAR. It is an alias of char by default and the code set used for the path name string is ANSI/OEM specifid by FF_CODE_PAGE. When FF_LFN_UNICODE is set to 1 or larger, the type of the TCHAR is switched to proper type to support the Unicode string. When Unicode API is specified by this option, the full-featured LFN specification is supported and the Unicode specific characters, such as ââªâ¡â¸â and any character not in BMP, can also be used for the path name. It also affects data types and encoding of the string I/O functions. To define literal strings, _T(s) and _TEXT(s) macro are available to specify the string in proper type. The code shown below is an example to define the literal strings.

- f_open(fp, "filename.txt", FA_READ);      /* ANSI/OEM string (char) */
- f_open(fp, L"filename.txt", FA_READ);     /* UTF-16 string (WCHAR) */
- f_open(fp, u8"filename.txt", FA_READ);    /* UTF-8 string (char) */
- f_open(fp, U"filename.txt", FA_READ);     /* UTF-32 string (DWORD) */
- f_open(fp, _T("filename.txt"), FA_READ);  /* Changed by configuration (TCHAR) */
+ f_open(fp, "filename.txt", FA_READ);      /* ANSI/OEM string (char) */
+ f_open(fp, L"filename.txt", FA_READ);     /* UTF-16 string (WCHAR) */
+ f_open(fp, u8"filename.txt", FA_READ);    /* UTF-8 string (char) */
+ f_open(fp, U"filename.txt", FA_READ);     /* UTF-32 string (DWORD) */
+ f_open(fp, _T("filename.txt"), FA_READ);  /* Changed by configuration (TCHAR) */

Volume Management

FatFs module requires dynamic work area, filesystem object, for each volume (logical drive). It is registered/unregistered to the FatFs module by f_mount function. By default, each logical drive is bound to the physical drive with the same drive number and an FAT volume on the drive is serched by the volume mount process. It reads boot sectors and checks it if it is an FAT boot sector in order of sector 0 as SFD format, 1st partition, 2nd partition, 3rd partition and 4th partition as FDISK format.

When FF_MULTI_PARTITION = 1 is specified by configuration option, each individual logical drive is bound to the partition on the physical drive specified by volume management table. The volume management table needs to be defined by user to resolve the mappings of logical drives and partitions. Following code is an example of a volume management table.

By default, each logical drive is associated with the physical drive in same drive number. An FAT volume on the physical drive is serched in the volume mount process. It reads boot sectors and checks it if it is an FAT VBR in order of LBA 0 as SFD format, 1st partition, 2nd partition, 3rd partition, ..., as MBR or GPT format.

When multiple partition feature is enabled, FF_MULTI_PARTITION = 1, each individual logical drive is associated with arbitrary partition or physical drive specified by volume management table, VolToPart[]. The table needs to be defined by user to resolve mappings of the logical drive numbers and the associated partitions or drives. Following code is an example of the volume management table.

-Example: "0:", "1:" and "2:" are tied to three pri-partitions on the physical drive 0 (fixed drive)
-         "3:" is tied to an FAT volume on the physical drive 1 (removable drive)
+Example: "0:", "1:" and "2:" are associated with three partitions on the physical drive 0 (a non-removable drive)
+         "3:" is associated with physical drive 1 (a removable drive)
 
 PARTITION VolToPart[FF_VOLUMES] = {
-    {0, 1},     /* "0:" ==> Physical drive 0, 1st partition */
-    {0, 2},     /* "1:" ==> Physical drive 0, 2nd partition */
-    {0, 3},     /* "2:" ==> Physical drive 0, 3rd partition */
-    {1, 0}      /* "3:" ==> Physical drive 1, auto detection */
+    {0, 1},     /* "0:" ==> 1st partition on the pd#0 */
+    {0, 2},     /* "1:" ==> 2nd partition on the pd#0 */
+    {0, 3},     /* "2:" ==> 3rd partition on the pd#0 */
+    {1, 0}      /* "3:" ==> pd#1 as removable drive (auto-search) */
 };
+
+
+

relationship between logical drive and physical drive

There are some considerations on using multi-partition configuration.

There are some considerations when enable the multi-partition configuration.

The physical drive that has two or more mounted partitions must be non-removable. Media change while a system operation is prohibited.
Only four primary partitions can be specified. Extended partition is not supported.
Windows does not support multiple volumes on the removable storage. Only first parition will be recognized.
The physical drive that hosts two or more mounted partitions should be non-removable, or all volumes on the drive must be unmounted when remove the medium.
When make any change to the VolToPart[], corresponding volume should be unmounted prior to make change the item.
On the MBR format drive, up to four primary partitions (1-4) can be specified. The partition number 1 specifies the first item in the partition table and the partition number 2 specifies the second one, and so on. The logical patitions (5-) in the extended partition is not supported.
On the GPT format drive, the partition number 1 specifies the first Microsoft BDP found in the partition table and the partition number 2 specifies the second one found, and so on.
Windows 10 earlier than 1703 does not support multiple volumes on the physical drive with removable class. Only the first parition found on the drive will be mounted. Windows OS does not support SFD format on the physical drive with non-removable class.
Some systems manage the on-board storage in non-standard partition format and each partition is mapped as physical drive in disk_* functions. For such system, FF_MULTI_PARTITION should be always 0.
For further information about the volume management, refer to the description in f_fdisk and f_mkfs.

Path Names on the FatFs

Path Names on the FatFs API

Format of the Path Names

Legal Characters and Case Sensitivity

Unicode API

Volume Management