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

FatFs R0.13c, released October 14, 2018

Browse Source
This commit is contained in:
Christopher Williams
2019-01-09 17:13:03 -07:00
parent ff793da7d3
commit f2bf030bfd
29 changed files with 361 additions and 257 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documents/doc/filename.html
+4 -4
View File
@@ -35,21 +35,21 @@
<tr><td>dir1/..</td><td>Invalid name</td><td>The current directory</td></tr>
<tr><td>/..</td><td>Invalid name</td><td>The root directory (sticks the top level)</td></tr>
</table>
<p>Also the drive prefix can be in pre-defined arbitrary string. When the option <tt><a href="config.html#str_volume_id">FF_STR_VOLUME_ID</a> == 1</tt>, also arbitrary string volume ID can be used as drive prefix. e.g. <tt>"flash:file1.txt"</tt>, <tt>"ram:temp.dat"</tt> or <tt>"usb:"</tt>. When <tt>FF_STR_VOLUME_ID == 2</tt>, Unix style drive prefix can be used. e.g. <tt>"/flash/file1.txt"</tt>, <tt>"/ram/temp.dat"</tt> or <tt>"/usb"</tt>. However, it cannot traverse the drives such as <tt>"/flash/../ram/temp.dat"</tt>. The Unix style drive prefix may lead a confusion in identification between volume ID and file name. For instance, which does <tt>"/flash"</tt> mean, a file <tt>"flash"</tt> on the root directory without drive prefix or a drive prefix of <tt>"flash"</tt>? If the string following a heading slash matches with any volume ID, it is treated as a drive prefix and skipped over.</p>
<p>Also the drive prefix can be in pre-defined arbitrary string. When the option <tt><a href="config.html#str_volume_id">FF_STR_VOLUME_ID</a> == 1</tt>, also arbitrary string volume ID can be used as drive prefix. e.g. <tt>"flash:file1.txt"</tt>, <tt>"ram:temp.dat"</tt> or <tt>"sd:"</tt>. When <tt>FF_STR_VOLUME_ID == 2</tt>, Unix style drive prefix can be used. e.g. <tt>"/flash/file1.txt"</tt>, <tt>"/ram/temp.dat"</tt> or <tt>"/usb"</tt>. However, it cannot traverse the drives such as <tt>"/flash/../ram/temp.dat"</tt>. The Unix style drive prefix may lead a confusion in identification between volume ID and file name. For instance, which does <tt>"/flash"</tt> mean, a file <tt>"flash"</tt> on the root directory without drive prefix or a drive prefix of <tt>"flash"</tt>? If the string following a heading slash matches with any volume ID, it is treated as a drive prefix.</p>
<p><em>Remark: In this revision, double dot name <tt>".."</tt> cannot follow the parent directory on the exFAT volume. It will work as <tt>"."</tt> and stay there.</em></p>
</div>
<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 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.</p>
<p>On the FAT filesystem, legal characters for object name (file/directory name) are, <tt>0-9 A-Z ! # $ % &amp; ' ( ) - @ ^ _ ` { } ~</tt> and any extended character. The valid character codes of extended characters are depends on the configured code page. Under LFN supported system, also <tt>+ , ; = [ ]</tt> 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 name.</p>
<p>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, <tt>file.txt</tt>, <tt>File.Txt</tt> and <tt>FILE.TXT</tt>, 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.</p>
<p>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.</p>
<p>As for the MS-DOS and PC DOS for CJK (DOS/DBCS), extended characters are recorded to the SFN entry without up-case conversion and compared in case-sensitive. This causes a problem on compatibility with Windows system when any 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 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).</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 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>
<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 or larger, the type of the <tt>TCHAR</tt> 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 ✝☪✡☸☭, 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 (char) */</span>
f_open(fp, L"filename.txt", FA_READ); <span class="c">/* UTF-16 string (WCHAR) */</span>