Github/fatfs
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

FatFs R0.13a, released October 14, 2017

Browse Source
This commit is contained in:
Christopher Williams
2017-11-11 23:43:22 -07:00
parent 5c7915feab
commit 7ee1f4cc87
61 changed files with 1240 additions and 779 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documents/doc/filename.html
+12 -11
View File
@@ -16,8 +16,8 @@
<h3>Format of the path names</h3>
<p>The format of path name on the FatFs module is similer to the filename specs of DOS/Windos as follows:</p>
<pre>[<em>drive#</em>:][/]<em>directory</em>/<em>file</em></pre>
<p>The FatFs module supports long file name (LFN) and 8.3 format file name (SFN). The LFN can be used when (<tt><a href="config.html#use_lfn">FF_USE_LFN</a> != 0</tt>). 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 logical drive is specified in a numeral with a colon. When drive prefix is omitted, the drive number is assumed as <em>default drive</em> (drive 0 or current drive).</p>
<p>Control characters (<tt>'\0'</tt> to <tt>'\x1F'</tt>) are recognized as end of the path name. Leading/embedded spaces in the path name are valid as a part of the name at LFN configuration but the space is recognized as end of the path name at non-LFN configuration. Trailing spaces and dots are ignored at both configurations.</p>
<p>The FatFs module supports long file name (LFN) and 8.3 format file name (SFN). The LFN can be used when <tt><a href="config.html#use_lfn">FF_USE_LFN</a> != 0</tt>. The sub directories are separated with a <tt>\</tt> or <tt>/</tt> in the same way as DOS/Windows API. Duplicated separators are skipped and ignored. Only a difference is that the logical drive is specified in a numeral with a colon. When drive prefix is omitted, the drive number is assumed as <em>default drive</em> (drive 0 or current drive).</p>
<p>Control characters (<tt>\0</tt> to <tt>\x1F</tt>) are recognized as end of the path name. Leading/embedded spaces in the path name are valid as a part of the name at LFN configuration but the space is recognized as end of the path name at non-LFN configuration. Trailing spaces and dots are ignored at both configurations.</p>
<p>In default configuration (<tt><a href="config.html#fs_rpath">FF_FS_RPATH</a> == 0</tt>), 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 (<tt>".", ".."</tt>) are not allowed. Heading separator is ignored and it can be exist or omitted. The default drive is fixed to drive 0.</p>
<p>When relative path is enabled (<tt>FF_FS_RPATH &gt;= 1</tt>), 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 <a href="chdir.html"><tt>f_chdir</tt></a> function. Dot names are also allowed for the path names. The default drive is the current drive set by <a href="chdrive.html"><tt>f_chdrive</tt></a> function.</p>
<table class="lst2">
@@ -41,28 +41,29 @@
<div class="para doc" id="case">
<h3>Legal Characters and Case Sensitivity</h3>
<p>On the FAT filesystem, legal characters for object name (file/directory name) are, <tt>0-9 A-Z ! # $ % &amp; ' ( ) - @ ^ _ ` { } ~</tt> and extended characters (<tt>\x80</tt>-<tt>\xFF</tt>). Under LFN supported system, also <tt>+ , ; = [ ]</tt> and space are legal for the object name and the white spaces and periods can be placed anywhere in the path name except for end of the object name.</p>
<p>FAT filesystem is case-insensitive to the object names on the volume. All object names are compared in case-insensitive. For example, these three names, <tt>file.txt</tt>, <tt>File.Txt</tt> and <tt>FILE.TXT</tt>, are identical. This is applied to also extended charactres. When an object is created on the FAT volume, upper converted name is recorded to the SFN entry, and the raw name is recorded to the LFN entry.</p>
<p>On the FAT filesystem, legal characters for object name (file/directory name) are, <tt>0-9 A-Z ! # $ % &amp; ' ( ) - @ ^ _ ` { } ~</tt> and extended characters (<tt>\x80</tt>-<tt>\xFF</tt>). Under LFN supported system, also <tt>+ , ; = [ ]</tt> and 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.</p>
<p>FAT filesystem is case-insensitive to the object names on the volume. All object names on the FAT volume are compared in case-insensitive. For example, these three names, <tt>file.txt</tt>, <tt>File.Txt</tt> and <tt>FILE.TXT</tt>, are identical. This is applied to also extended charactres. When an object is created on the FAT volume, upper converted name is recorded to the SFN entry, and the raw name is recorded to the LFN entry.</p>
<p>As for the DBCS language MS-DOS, it was case-sensitive to the 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 all characters (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.</p>
</div>
<div class="para doc" id="uni">
<h3>Unicode API</h3>
<p>The path names are input/output in either ANSI/OEM code or Unicode depends on the configuration options. The type of arguments which specify the path names are defined as <tt>TCHAR</tt>. It is an alias of <tt>char</tt> by default. The code set used to the path name string is ANSI/OEM specifid by <tt><a href="config.html#code_page">FF_CODE_PAGE</a></tt>. When <tt><a href="config.html#lfn_unicode">FF_LFN_UNICODE</a></tt> is set to 1, the type of the <tt>TCHAR</tt> is switched to <tt>WCHAR</tt> to support Unicode (UTF-16 encoding). In this case, 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, <tt>_T(s)</tt> and <tt>_TEXT(s)</tt> macro are available to select either ANSI/OEM or Unicode automatically. The code shown below is an example to define the literal strings.</p>
<p>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 <tt>TCHAR</tt>. It is an alias of <tt>char</tt> by default and the code set used for the path name string is ANSI/OEM specifid by <tt><a href="config.html#code_page">FF_CODE_PAGE</a></tt>. When <tt><a href="config.html#lfn_unicode">FF_LFN_UNICODE</a></tt> is set to 1, the type of the <tt>TCHAR</tt> is switched to <tt>WCHAR</tt> 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, <tt>_T(s)</tt> and <tt>_TEXT(s)</tt> macro are available to select either ANSI/OEM or Unicode automatically. The code shown below is an example to define the literal strings.</p>
<pre>
f_open(fp, "filename.txt", FA_READ); <span class="c">/* ANSI/OEM string */</span>
f_open(fp, L"filename.txt", FA_READ); <span class="c">/* Unicode string */</span>
f_open(fp, _T("filename.txt"), FA_READ); <span class="c">/* Changed by configuration */</span>
f_open(fp, "filename.txt", FA_READ); <span class="c">/* ANSI/OEM string (char) */</span>
f_open(fp, L"filename.txt", FA_READ); <span class="c">/* UTF-16 string (WCHAR) */</span>
f_open(fp, u8"filename.txt", FA_READ); <span class="c">/* UTF-8 string (char) */</span>
f_open(fp, _T("filename.txt"), FA_READ); <span class="c">/* Changed by configuration (TCHAR) */</span>
</pre>
</div>
<div class="para doc" id="vol">
<h3>Volume Management</h3>
<p>FatFs module needs dynamic work area, <em>filesystem object</em>, for each volume (logical drive). It is registered/unregistered to the FatFs module by <tt>f_mount</tt> 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.</p>
<p>When <tt><a href="config.html#multi_partition">FF_MULTI_PARTITION</a> == 1</tt> 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.</p>
<p>When <tt><a href="config.html#multi_partition">FF_MULTI_PARTITION = 1</a></tt> 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.</p>
<pre>
Example: 0:-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 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)
PARTITION VolToPart[FF_VOLUMES] = {
{0, 1}, <span class="c">/* "0:" ==> Physical drive 0, 1st partition */</span>