92 lines
11 KiB
HTML
92 lines
11 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
|
<html lang="en">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
|
<meta http-equiv="Content-Style-Type" content="text/css">
|
|
<link rel="up" title="FatFs" href="../00index_e.html">
|
|
<link rel="alternate" hreflang="ja" title="Japanese" href="../ja/filename.html">
|
|
<link rel="stylesheet" href="../css_e.css" type="text/css" media="screen" title="ELM Default">
|
|
<title>FatFs - Path Names</title>
|
|
</head>
|
|
|
|
<body>
|
|
<h1>Path Names on the FatFs API</h1>
|
|
|
|
<div class="para doc" id="nam">
|
|
<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> >= 1</tt>. The sub-directories are separated with a <tt>\</tt> or <tt>/</tt> as the same way as DOS/Windows API. Duplicated separators are skipped and ignored. Only a difference is that the heading drive prefix to specify the logical drive number is in a numeral (0-9) + a colon, while it is an alphabet (A-Z) + a colon in DOS/Windows. The logical drive number is identifier to specify the FAT volume to be accessed. When drive prefix is omitted, the logical drive number is assumed as <em>default drive</em>.</p>
|
|
<p>Control characters (<tt>\0</tt> to <tt>\x1F</tt>) are recognized as end of the path name. Leading/embedded white spaces in the path name are valid as a part of the name in LFN configuration but the white space is recognized as end of the path name in non-LFN configuration. Trailing white spaces and dots are ignored in 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 >= 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">
|
|
<tr><td>Path name</td><td>FF_FS_RPATH == 0</td><td>FF_FS_RPATH >= 1</td></tr>
|
|
<tr class="lst3"><td>file.txt</td><td>A file in the root directory of the drive 0</td><td>A file in the current directory of the current drive</td></tr>
|
|
<tr><td>/file.txt</td><td>A file in the root directory of the drive 0</td><td>A file in the root directory of the current drive</td></tr>
|
|
<tr><td></td><td>The root directory of the drive 0</td><td>The current directory of the current drive</td></tr>
|
|
<tr><td>/</td><td>The root directory of the drive 0</td><td>The root directory of the current drive</td></tr>
|
|
<tr><td>2:</td><td>The root directory of the drive 2</td><td>The current directory of the drive 2</td></tr>
|
|
<tr><td>2:/</td><td>The root directory of the drive 2</td><td>The root directory of the drive 2</td></tr>
|
|
<tr><td>2:file.txt</td><td>A file in the root directory of the drive 2</td><td>A file in the current directory of the drive 2</td></tr>
|
|
<tr><td>../file.txt</td><td>Invalid name</td><td>A file in the parent directory</td></tr>
|
|
<tr><td>.</td><td>Invalid name</td><td>This directory</td></tr>
|
|
<tr><td>..</td><td>Invalid name</td><td>Parent directory of the current directory (*)</td></tr>
|
|
<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>"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 ! # $ % & ' ( ) - @ ^ _ ` { } ~</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 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 (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 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 in only non-LFN with DBCS configuration (DOS/DBCS specs). But in 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 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 specify the string in proper type. The code shown below is an example to define the literal strings.</p>
|
|
<pre>
|
|
f_open(fp, <span class="e">"filename.txt"</span>, FA_READ); <span class="c">/* ANSI/OEM string (char) */</span>
|
|
f_open(fp, <span class="e">L"filename.txt"</span>, FA_READ); <span class="c">/* UTF-16 string (WCHAR) */</span>
|
|
f_open(fp, <span class="e">u8"filename.txt"</span>, FA_READ); <span class="c">/* UTF-8 string (char) */</span>
|
|
f_open(fp, <span class="e">U"filename.txt"</span>, FA_READ); <span class="c">/* UTF-32 string (DWORD) */</span>
|
|
f_open(fp, <span class="e">_T("filename.txt")</span>, FA_READ); <span class="c">/* Changed by configuration (TCHAR) */</span>
|
|
</pre>
|
|
</div>
|
|
|
|
<div class="para doc" id="vol">
|
|
<h3>Volume Management</h3>
|
|
<p>By default, each logical drive is associated with the physical drive in same drive number. An FAT volume on the physical 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 LBA 0 as SFD format, 1st partition, 2nd partition, 3rd partition, ..., as MBR or GPT format.</p>
|
|
<p>When multiple partition feature is enabled, <tt><a href="config.html#multi_partition">FF_MULTI_PARTITION = 1</a></tt>, each individual logical drive is associated with arbitrary partition or drive specified by volume management table, <tt>VolToPart[]</tt>. The 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:", "1:" and "2:" are associated with three partitions on the physical drive 0 (fixed drive)
|
|
"3:" is associated with physical drive 1 (removable drive)
|
|
|
|
PARTITION VolToPart[FF_VOLUMES] = {
|
|
{0, 1}, <span class="c">/* "0:" ==> 1st partition of physical drive 0 */</span>
|
|
{0, 2}, <span class="c">/* "1:" ==> 2nd partition of physical drive 0 */</span>
|
|
{0, 3}, <span class="c">/* "2:" ==> 3rd partition of physical drive 0 */</span>
|
|
{1, 0} <span class="c">/* "3:" ==> Physical drive 1 */</span>
|
|
};
|
|
</pre>
|
|
<div><img src="../res/f7.png" width="900" height="288" alt="relationship between logical drive and physical drive"></div>
|
|
<p>There are some considerations on using multi-partition configuration.</p>
|
|
<ul>
|
|
<li>The physical drive that hosts two or more mounted partitions must be non-removable, or all volumes on the drive must be unmounted when remove the medium.</li>
|
|
<li>When make any change to the <tt>VolToPart[]</tt>, corresponding volume should be unmounted prior to make change the item.</li>
|
|
<li>On the MBR format drive, up to four primary partitions (1-4) can be specified. The partition 1 specifies the first item in the partition table and the partition 2 specifies the second one, and so on. Logical patitions in the extended partition is not supported.</li>
|
|
<li>On the GPT format drive, there is no limitation. The partition 1 specifies the first Microsoft basic data partition found in the partition table and the partition 2 specifies the second one found, and so on.</li>
|
|
<li>Windows does not support multiple volumes on the storage with removable class. Only the first parition found on the drive will be mounted.</li>
|
|
<li>For further information, refer to <tt><a href="fdisk.html">f_fdisk</a></tt> and <tt><a href="mkfs.html">f_mkfs</a></tt>function.</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<p class="foot"><a href="../00index_e.html">Return</a></p>
|
|
</body>
|
|
</html>
|