FatFs R0.13c, released October 14, 2018

documents/doc/appnote.html

@@ -32,22 +32,28 @@
 <h3>How to Port</h3>
 
 <h4>Basic Considerations</h4>
-<p>The FatFs module is assuming following conditions on portability.</p>
+<p>The FatFs module assumes following conditions on portability.</p>
 <ul>
 <li>ANSI C<br>
-The FatFs module is a middleware written in ANSI C (C89). There is no platform dependence, so long as the compiler is in compliance with ANSI C.</li>
+The FatFs module is a middleware written in ANSI C (C89). There is no platform dependence, so long as the compiler is in compliance with C89 or later. Only exFAT feature requires C99.</li>
 <li>Size of integer types<br>
-The FatFs module assumes that size of <tt>char</tt>/<tt>short</tt>/<tt>long</tt> are 8/16/32 bit and <tt>int</tt> is 16 or 32 bit. These correspondence are defined in <tt>integer.h</tt>. This will not be a problem on most compilers. When a conflict with existing definitions is occured, you must resolve it with care.</li>
+<ul>
+<li>When the C standard is in C89, size of <tt>char</tt>/<tt>short</tt>/<tt>long</tt> must be 8/16/32-bit respectively.</li>
+<li>When it is in C99 or later, <tt>stdint.h</tt> is used to obtain the correct sizes.</li>
+<li>Size of <tt>char</tt> must be 8-bit.</li>
+<li>Size of <tt>int</tt>, as well as integer promotion, must be 16-bit or 32-bit.</li>
+</ul>
+Integer types used in FatFs are defined in <tt>fftypes.h</tt>. This will not be a problem on most platform. When a conflict with existing definitions occured, you must resolve it with care.</li>
 </ul>
 
 <h4>System Organizations</h4>
-<p>The dependency diagram shown below is a typical but not specific configuration of the embedded system with FatFs module.</p>
+<p>The dependency diagram shown below is a typical, but not specific, configuration of the embedded system with FatFs module.</p>
 <p><img src="../res/modules.png" width="580" height="280" alt="dependency diagram"></p>
-<p>(a) If a working disk module with FatFs disk interface is provided, nothing else will be needed. (b) To attach existing disk drivers with different interface, glue functions are needed to translate the interfaces between FatFs and the drivers.</p>
+<p>(a) If a working disk module for FatFs is provided, nothing else will be needed. (b) To attach existing disk drivers with different interface, some glue functions are needed to translate the interfaces between FatFs and the driver.</p>
 <p><img src="../res/funcs.png" width="750" height="420" alt="functional diagram"></p>
 
 <h4>Required Functions</h4>
-<p>You need to provide only low level disk I/O functions required by FatFs module and nothing else. If a working disk module for the target system is already provided, you need to write only glue functions to attach it to the FatFs module. If not, you need to port another disk I/O module or write it from scratch. Most of defined functions are not that always required. For example, any write function is not required at read-only configuration. Following table shows which function is required depends on the configuration options.</p>
+<p>You need to provide only low level disk I/O functions required by FatFs module and nothing else. If a working disk I/O module for the target system is already provided, you need to write only glue functions to attach it to the FatFs module. If not, you need to port another disk I/O module or write it from scratch. Most of defined functions are not that always required. For instance, any write function is not required at read-only configuration. Following table shows which function is required depends on the configuration options.</p>
 <table class="lst2">
 <tr><th>Function</th><th>Required when</th><th>Note</th></tr>
 <tr><td>disk_status<br>disk_initialize<br>disk_read</td><td>Always</td><td rowspan="5">Disk I/O functions.<br>Samples available in ffsample.zip.<br>There are many implementations on the web.</td></tr>
@@ -55,10 +61,11 @@ The FatFs module assumes that size of <tt>char</tt>/<tt>short</tt>/<tt>long</tt>
 <tr><td>disk_ioctl (GET_SECTOR_COUNT)<br>disk_ioctl (GET_BLOCK_SIZE)</td><td>FF_USE_MKFS == 1</td></tr>
 <tr><td>disk_ioctl (GET_SECTOR_SIZE)</td><td>FF_MAX_SS != FF_MIN_SS</td></tr>
 <tr><td>disk_ioctl (CTRL_TRIM)</td><td>FF_USE_TRIM == 1</td></tr>
-<tr><td>ff_uni2oem<br>ff_oem2uni<br>ff_wtoupper</td><td>FF_USE_LFN != 0</td><td>Unicode support functions.<br>Just add ffunicode.c to the project.</td></tr>
-<tr><td>ff_cre_syncobj<br>ff_del_syncobj<br>ff_req_grant<br>ff_rel_grant</td><td>FF_FS_REENTRANT == 1</td><td rowspan="2">O/S dependent functions.<br>Samples available in ffsystem.c.</td></tr>
+<tr><td>ff_uni2oem<br>ff_oem2uni<br>ff_wtoupper</td><td>FF_USE_LFN != 0</td><td>Unicode support functions.<br>Add optional module ffunicode.c to the project.</td></tr>
+<tr><td>ff_cre_syncobj<br>ff_del_syncobj<br>ff_req_grant<br>ff_rel_grant</td><td>FF_FS_REENTRANT == 1</td><td rowspan="2">O/S dependent functions.<br>Sample code is available in ffsystem.c.</td></tr>
 <tr><td>ff_mem_alloc<br>ff_mem_free</td><td>FF_USE_LFN == 3</td></tr>
 </table>
+<p>FatFs cares about neither what kind of storage device is used nor how it is implemented. Only a requirement is that it is a block device read/written in fixed-size blocks that accessible via the disk I/O functions defined above.</p>
 </div>
 
 <div class="para doc" id="limits">
@@ -89,13 +96,13 @@ The FatFs module assumes that size of <tt>char</tt>/<tt>short</tt>/<tt>long</tt>
 <tr class="ral"><td class="cal">Work area<br><small>(FF_FS_TINY == 0)</small></td><td>V*564<br>+ F*552</td><td>V*564<br>+ F*552</td><td>V*564<br>+ F*552</td><td>V*560<br>+ F*546</td><td>V*560<br>+ F*546</td><td>V*560<br>+ F*546</td><td>V*560<br>+ F*546</td><td>V*564<br>+ F*552</td><td>V*564<br>+ F*552</td><td>V*564<br>+ F*552</td><td>V*564<br>+ F*552</td></tr>
 <tr class="ral"><td class="cal">Work area<br><small>(FF_FS_TINY == 1)</small></td><td>V*564<br>+ F*40</td><td>V*564<br>+ F*40</td><td>V*564<br>+ F*40</td><td>V*560<br>+ F*34</td><td>V*560<br>+ F*34</td><td>V*560<br>+ F*34</td><td>V*560<br>+ F*34</td><td>V*564<br>+ F*40</td><td>V*564<br>+ F*40</td><td>V*564<br>+ F*40</td><td>V*564<br>+ F*40</td></tr>
 </table>
-<p>These are the memory usage on some target systems with following condition. The memory sizes are in unit of byte, <em>V</em> denotes number of mounted volumes and <em>F</em> denotes number of open files. All samples here are optimezed in code size.</p>
+<p>These are the memory usage of FatFs module without lower layer on some target systems in following condition. <em>V</em> denotes number of mounted volumes and <em>F</em> denotes number of open files. Every samples here are optimezed in code size.</p>
 <pre>
 FatFs R0.13a options:
 FF_FS_READONLY   0 (Read/Write) or 1 (Read only)
 FF_FS_MINIMIZE   0 (Full, with all basic functions) or 3 (Min, with fully minimized)
 FF_FS_TINY       0 (Default) or 1 (Tiny file object)
-And other options are left unchanged from original setting.
+And any other options are left unchanged from original setting.
 </pre>
 </div>
 
@@ -146,8 +153,8 @@ And other options are left unchanged from original setting.
 <h3>Long File Name</h3>
 <p>FatFs module supports long file name (LFN). The two different file names, short file name (SFN) and LFN, of a file is transparent on the API except for <tt>f_readdir</tt> function. The support for LFN is disabled by default. To enable the LFN, set <tt><a href="config.html#use_lfn">FF_USE_LFN</a></tt> to 1, 2 or 3, and add <tt>ffunicode.c</tt> to the project. The LFN requiers a certain working buffer in addition. The buffer size can be configured by <tt><a href="config.html#max_lfn">FF_MAX_LFN</a></tt> according to the available memory. The length of an LFN will be up to 255 characters, so that the <tt>FF_MAX_LFN</tt> should be set to 255 for all file names. If the size of working buffer is insufficient for the input file name, the file function fails with <tt>FR_INVALID_NAME</tt>. When use any re-entry to the API with LFN is enabled, <tt>FF_USE_LFN</tt> must be set to 2 or 3. In this case, the file function allocates the working buffer on the stack or heap. The working buffer occupies <tt>(FF_MAX_LFN + 1) * 2</tt> bytes and additional <tt>(FF_MAX_LFN + 44) / 15 * 32</tt> bytes when exFAT is enabled.</p>
 <table class="lst2 rset">
-<caption>With LFN at CM3+gcc</caption>
-<tr><th><tt>FF_CODE_PAGE</tt></th><th>Increment</th></tr>
+<caption>With LFN at CM3 + gcc</caption>
+<tr><th><tt>FF_CODE_PAGE</tt></th><th>Code size</th></tr>
 <tr><td>437-869 (SBCS)</td><td>+3.3k</td></tr>
 <tr><td>932 (Japanese)</td><td>+62k</td></tr>
 <tr><td>936 (Simplified Chinese)</td><td>+177k</td></tr>
@@ -155,22 +162,22 @@ And other options are left unchanged from original setting.
 <tr><td>950 (Traditional Chinese)</td><td>+111k</td></tr>
 <tr><td>0 (All code pages)</td><td>+486k</td></tr>
 </table>
-<p>When the LFN is enabled, the module size will be increased depends on the configured code page. Right table shows increment of code size by LFN function at different code pages. Especially, in the CJK region, tens of thousands of characters are being used. Unfortunately, it requires a huge OEM-Unicode bidirectional conversion table and the module size will be drastically increased as shown in the table. As the result, the FatFs with LFN enebled with those code pages will not able to be ported on the most 8-bit MCU systems.</p>
-<p>If you can discard ANSI/OEM code API and backward compatibility with non-ASCII SFN, you will able to configure FatFs for Unicode API with any SBCS.</p>
-<p>There ware some restrictions on using LFN for open source project because the support for LFN on the FAT volume was a patent of Microsoft Corporation. The related patents have expired and using the LFN function have got free for any projects.</p>
+<p>When the LFN is enabled, the module size will be increased depends on the configured code page. Right table shows increment of code size by LFN function at different code pages. Especially, in the CJK region, tens of thousands of characters are being used. Unfortunately, it requires a huge OEM-Unicode bidirectional conversion table and the module size will be drastically increased as shown in the table.</p>
+<p>As the result, the FatFs with LFN enebled with DBCS code pages will not able to be ported on the most 8-bit MCU systems. If the target system is in legacy-free, in only Unicode and any ANSI/OEM code is not used at all, the code page setting gets meaningless. You will able to reduce the code size by configureing FatFs for Unicode with any SBCS code page.</p>
+<p>There ware some restrictions on using LFN for open source project because the support for LFN on the FAT volume was a patent of Microsoft Corporation. The related patents have expired and using the LFN function has got free for any projects.</p>
 </div>
 
 <div class="para doc" id="unicode">
 <h3>Unicode API</h3>
-<p>By default, FatFs uses ANSI/OEM code set on the API even at LFN configuration. FatFs can also switch the character encoding on the API to Unicode by configuration option <tt><a href="config.html#lfn_unicode">FF_LFN_UNICODE</a></tt>. This means that FatFs supports the full featured LFN specification. The data type <tt>TCHAR</tt> specifies path name strings on the API is an alias of either <tt>char</tt>(ANSI/OEM or UTF-8), <tt>WCHAR</tt>(UTF-16) or <tt>DWORD</tt>(UTF-32) depends on that option. For more information, refer to the description in the <a href="filename.html#uni">file name</a>.</p>
-<p>Note that code page setting, <tt><a href="config.html#code_page">FF_CODE_PAGE</a></tt>, has actually no meaning for the path names at the Unicode API. However it still affects code conversion of string I/O functions at <tt><a href="config.html#strf_encode">FF_STRF_ENCODE</a> != 0</tt> and backward compatibility with legacy systems, so that code page needs to be configured properly when it is considered a problem.</p>
+<p>By default, FatFs uses ANSI/OEM code set on the API even at LFN configuration. FatFs can also switch the character encoding on the API to Unicode by configuration option <tt><a href="config.html#lfn_unicode">FF_LFN_UNICODE</a></tt>. This means that FatFs is compliant with the full featured LFN specification. The data type <tt>TCHAR</tt> specifies path name strings on the API is an alias of either <tt>char</tt>(ANSI/OEM or UTF-8), <tt>WCHAR</tt>(UTF-16) or <tt>DWORD</tt>(UTF-32) depends on that option. For more information, refer to the description in the <a href="filename.html#uni">file name</a>.</p>
+<p>Note that setting of code page, <tt><a href="config.html#code_page">FF_CODE_PAGE</a></tt>, has actually no meaning when FatFs is configured for the Unicode API. It should be set 437 anyway. However it still affects code conversion of string I/O functions at <tt><a href="config.html#strf_encode">FF_STRF_ENCODE</a> == 0</tt> and backward compatibility with legacy systems, so that code page may need to be configured properly if it is considered a problem.</p>
 </div>
 
 <div class="para doc" id="exfat">
 <h3>exFAT Filesystem</h3>
-<p>The exFAT (Microsoft's Extended File Allocation Table) filesystem is a succession of the FAT/FAT32 filesystem which has been widely used in embedded systems, consumer devices and portable storage media. It is adopted by SDA (SD Association) as a recommended filesystem for high capacity SD cards larger than 32 GB and they are being shipped with this format, so that the exFAT became one of the standard filesystems for removable media as well as FAT. The exFAT filesystem allows the file size beyond the 4 GB limit what FAT filesystem allows upto and some filesystem overhead, especially cluster allocation delay, are reduced as well. This feature improves the write throughput to the file.</p>
-<p>Note that the exFAT is a patent of Microsoft Corporation. The exFAT function of FatFs is an implementation based on <cite>US. Pat. App. Pub. No. 2009/0164440 A1</cite>. FatFs module can switch the support for exFAT on/off by configuration option, <tt><a href="config.html#fs_exfat">FF_FS_EXFAT</a></tt>. When enable the exFAT on the commercial products, a license by Microsoft will be needed depends on the final destination of the products.</p>
-<p><em>Remark: Enabling exFAT discards ANSI C (C89) compatibility because of need for 64-bit integer type.</em></p>
+<p>The exFAT (Microsoft's Extended File Allocation Table) filesystem is a succession of the FAT/FAT32 filesystem which has been widely used in embedded systems, consumer devices and portable storage media. It is adopted by SDA (SD Association) as the regular filesystem for SDXC card, 64 GB and larger, and they are being shipped with this format. Therefore the exFAT is one of the standard filesystems for removable media as well as FAT. The exFAT filesystem allows the file size beyond the 4 GB limit what FAT filesystem allows upto and some filesystem overhead, especially cluster allocation delay, are reduced as well. These features allow to record the large media file without dividing into some files and improve the write throughput to the file.</p>
+<p>Note that the exFAT is a patent of Microsoft Corporation. The support for exFAT of FatFs is an implementation based on <cite>US. Pat. App. Pub. No. 2009/0164440 A1</cite>. FatFs module can switch the exFAT on or off by configuration option, <tt><a href="config.html#fs_exfat">FF_FS_EXFAT</a></tt>. When enable the exFAT on the commercial products, a license by Microsoft will be needed depends on the final destination of the products.</p>
+<p><em>Remark: Enabling exFAT discards C89 compatibility because of need for 64-bit integer type.</em></p>
 </div>
 
 <div class="para doc" id="reentrant">
@@ -245,11 +252,12 @@ Figure 5. Minimized critical section<br>
 <h3>Extended Use of FatFs API</h3>
 <p>These are examples of extended use of FatFs APIs. New item will be added whenever a useful code is found.</p>
 <ol>
-<li><a href="http://elm-chan.org/fsw/ff/res/app1.c">Open or create a file for append</a> (for only R0.12 and earlier)</li>
-<li><a href="http://elm-chan.org/fsw/ff/res/app2.c">Empty a directory</a></li>
-<li><a href="http://elm-chan.org/fsw/ff/res/app3.c">Allocate contiguous area to the file</a> (for only R0.11a and earlier)</li>
+<li><a href="http://elm-chan.org/fsw/ff/res/app1.c">Open or create a file for append</a> (for R0.12 and earlier)</li>
+<li><a href="http://elm-chan.org/fsw/ff/res/app2.c">Delete a non-empty sub-directory</a> (for R0.12 and later)</li>
+<li><a href="http://elm-chan.org/fsw/ff/res/app3.c">Allocate contiguous area to the file</a> (for R0.11a and earlier)</li>
 <li><a href="http://elm-chan.org/fsw/ff/res/app4.c">Compatibility checker for low level disk I/O module</a></li>
 <li><a href="http://elm-chan.org/fsw/ff/res/mkfatimg.zip">FAT volume image creator</a></li>
+<li><a href="http://elm-chan.org/fsw/ff/res/app5.c">Test if the file is contiguous or not</a></li>
 </ol>
 </div>
 

documents/doc/config.html

@@ -116,10 +116,10 @@
 <h3>Namespace and Locale Configurations</h3>
 
 <h4 id="code_page">FF_CODE_PAGE</h4>
-<p>This option specifies the OEM code page to be used on the target system. Incorrect setting of the code page can cause a file open failure. If any non-ASCII character is not used at all, there is no difference between any code page settings.</p>
+<p>This option specifies the OEM code page to be used on the target system. Incorrect setting of the code page can cause a file open failure. If any non-ASCII character is not used for the path name, there is no difference between any code page settings. Set it 437 anyway.</p>
 <table class="lst1">
 <tr><th>Value</th><th>Code page</th></tr>
-<tr><td>0</td><td>Include all code pages below and set by <tt>f_setcp()</tt></td></tr>
+<tr><td>0</td><td>Includes all code pages below and set by <tt>f_setcp()</tt></td></tr>
 <tr><td>437</td><td>U.S.</td></tr>
 <tr><td>720</td><td>Arabic</td></tr>
 <tr><td>737</td><td>Greek</td></tr>
@@ -157,7 +157,7 @@
 <p>LFN function requiers certain internal working buffer for the file name. This option defines size of the buffer and the value can be in range of 12 to 255 in UTF-16 encoding unit of the LFN. The buffer occupies <tt>(FF_MAX_LFN + 1) * 2</tt> bytes and additional <tt>(FF_MAX_LFN + 44) / 15 * 32</tt> bytes when exFAT is enabled. It is recommended to be set 255 to fully support the LFN specification. This option has no effect when LFN is not enabled.</p>
 
 <h4 id="lfn_unicode">FF_LFN_UNICODE</h4>
-<p>This option switches character encoding for the file name on the API. When Unicode is selected, <tt>FF_CODE_PAGE</tt> has actually no meaning except for compatibility with legacy systems. FatFs supports the code point upto U+10FFFF.</p>
+<p>This option switches character encoding for the file name on the API. When Unicode is selected, <tt>FF_CODE_PAGE</tt> has actually no meaning except for compatibility with legacy systems, such as MS-DOS and any system without support for LFN. FatFs supports the code point upto U+10FFFF.</p>
 <table class="lst2">
 <tr><th>Value</th><th>Character Encoding</th><th><tt>TCHAR</tt></th></tr>
 <tr><td>0</td><td>ANSI/OEM in current CP</td><td>char</td></tr>
@@ -168,7 +168,7 @@
 <p>This option also affects behavior of string I/O functions (see <tt>FF_STRF_ENCODE</tt>). When LFN is not enabled, this option has no effect and FatFs works at ANSI/OEM code on the API. For more information, read <a href="filename.html#uni">here</a>.</p>
 
 <h4 id="lfn_buf">FF_LFN_BUF, FF_SFN_BUF</h4>
-<p>This set of options defines size of file name members, <tt>fname[]</tt> and <tt>altname[]</tt>, in the <tt><a href="sfileinfo.html">FILINFO</a></tt> structure which is used to read out the directory items. These values should be suffcient for the file names to read. How long is the read file name length maximum depends on the character encoding on the API as follows:</p>
+<p>This set of options defines size of file name members, <tt>fname[]</tt> and <tt>altname[]</tt>, in the <tt><a href="sfileinfo.html">FILINFO</a></tt> structure which is used to read out the directory items. These values should be suffcient for the file names to read. The maximum possible length of read file name depends on the character encoding on the API as follows:</p>
 <table class="lst2">
 <tr><th>Encoding</th><th>LFN length</th><th>SFN length</th></tr>
 <tr><td>ANSI/OEM at SBCS</td><td>255 items</td><td>12 items</td></tr>
@@ -179,7 +179,7 @@
 <p>If the size of name member is insufficient for the LFN, the item is treated as without LFN. When LFN is not enabled, these options have no effect.</p>
 
 <h4 id="strf_encode">FF_STRF_ENCODE</h4>
-<p>When character encoding on the API is Unicode (<tt>FF_LFN_UNICODE &gt;= 1</tt>), string I/O functions, <tt>f_gets</tt>, <tt>f_putc</tt>, <tt>f_puts</tt> and <tt>f_printf</tt>, convert the character encodins in it. This option defines the assumption of character encoding <em>on the file</em> to be read/written via those functions. When LFN is not enabled or <tt>FF_LFN_UNICODE == 0</tt>, the string functions work without any encoding conversion and this option has no effect.</p>
+<p>When character encoding on the API is Unicode (<tt>FF_LFN_UNICODE &gt;= 1</tt>), string I/O functions, <tt>f_gets</tt>, <tt>f_putc</tt>, <tt>f_puts</tt> and <tt>f_printf</tt>, convert the character encoding in it. This option defines the assumption of character encoding <em>on the file</em> to be read/written via those functions. When LFN is not enabled or <tt>FF_LFN_UNICODE == 0</tt>, the string functions work without any encoding conversion and this option has no effect.</p>
 <table class="lst2">
 <tr><th>Value</th><th>Character encoding on the file</th></tr>
 <tr><td>0</td><td>ANSI/OEM in current code page</td></tr>
@@ -216,7 +216,7 @@
 </table>
 
 <h4 id="volume_strs">FF_VOLUME_STRS</h4>
-<p>This option defines the volume ID strings for each logical drives. Number of items must not be less than <tt>FF_VOLUMES</tt>. Valid characters for the volume ID string are A-Z, a-z and 0-9, however, they are compared in case-insensitive. If <tt>FF_STR_VOLUME_ID == 0</tt>, this option has no effect. If <tt>FF_STR_VOLUME_ID &gt;= 1</tt> and this option is not defined, a user defined volume string table needs to be defined as shown below.</p>
+<p>This option defines the volume ID strings for each logical drives. Number of items must not be less than <tt>FF_VOLUMES</tt>. Valid characters for the volume ID string are A-Z, a-z and 0-9, however, they are compared in case-insensitive. If <tt>FF_STR_VOLUME_ID == 0</tt>, this option has no effect. If <tt>FF_STR_VOLUME_ID &gt;= 1</tt> and this option is not defined, a user defined volume string table needs to be defined as shown below. The table should not be modified on the fly.</p>
 <pre>
 <span class="c">/* User defined volume ID strings for 0:    1:      2:    3:   ... */</span>
 const char* VolumeStr[FF_VOLUMES] = {"ram","flash","sdc","usb"};
@@ -268,7 +268,7 @@ const char* VolumeStr[FF_VOLUMES] = {"ram","flash","sdc","usb"};
 </table>
 
 <h4 id="fs_reentrant">FF_FS_REENTRANT</h4>
-<p>Disable (0) or Enable (1). This option switches the re-entrancy (thread safe) of the FatFs module itself. Note that file/directory access to the different volume is always re-entrant and it can work simultaneously regardless of this option but volume control functions. <tt>f_mount</tt>, <tt>f_mkfs</tt> and <tt>f_fdisk</tt>, are always not re-entrant. Only file/directory access to the same volume, in other words, exclusive use of each filesystem object, is under control of this function. To enable this feature, also user provided synchronization handlers, <tt>ff_req_grant</tt>, <tt>ff_rel_grant</tt>, <tt>ff_del_syncobj</tt> and <tt>ff_cre_syncobj</tt>, need to be added to the project. Sample code is available in <tt>ffsystem.c</tt>.</p>
+<p>Disable (0) or Enable (1). This option switches the re-entrancy (thread safe) of the FatFs module itself. Note that file/directory access to the different volume is always re-entrant and it can work simultaneously regardless of this option, however, volume management functions, <tt>f_mount</tt>, <tt>f_mkfs</tt> and <tt>f_fdisk</tt>, are always not re-entrant. Only file/directory access to the same volume, in other words, exclusive use of each filesystem object, is under control of this function. To enable this feature, also user provided synchronization handlers, <tt>ff_req_grant</tt>, <tt>ff_rel_grant</tt>, <tt>ff_del_syncobj</tt> and <tt>ff_cre_syncobj</tt>, need to be added to the project. Sample code is available in <tt>ffsystem.c</tt>.</p>
 
 <h4 id="fs_timeout">FF_FS_TIMEOUT</h4>
 <p>Number of time ticks to abort the file function with <tt>FR_TIMEOUT</tt> when wait time is too long. This option has no effect when <tt>FF_FS_REENTRANT == 0</tt>.</p>

documents/doc/dread.html

@@ -61,7 +61,7 @@ DRESULT disk_read (
 <ul>
 <li>Convert word transfer to byte transfer in this function if needed. - Recommended.</li>
 <li>On the <tt>f_read()</tt> calls, avoid long read request that includes a whole of sector. - Any direct transfer never occures.</li>
-<li>On the <tt>f_read(fp, dat, btw, bw)</tt> calls, make sure that <tt>(((UINT)dat &amp; 3) == (f_tell(fp) &amp; 3))</tt> is true. - Word alignment of <tt class="arg">buff</tt> is guaranteed no matter dat is not word aligned.</li>
+<li>On the <tt>f_read(fp, dat, btw, bw)</tt> calls, make sure that <tt>(((UINT)dat &amp; 3) == (f_tell(fp) &amp; 3))</tt> is true. - Word alignment of <tt class="arg">buff</tt> is guaranteed.</li>
 </ul>
 <p>Generally, a multiple sector read request must not be split into single sector transactions to the storage device, or read throughput gets worse.</p>
 </div>

documents/doc/expand.html

@@ -61,7 +61,7 @@ FRESULT f_expand (
 </ul>
 <p>When <tt class="arg">opt</tt> is 0, the function finds a contiguous data area and set it as suggested point for next allocation instead of allocating it to the file. The next cluster allocation is started at top of the contiguous area found by this function. Thus the write file is guaranteed be contiguous and no allocation delay until the size reaches that size at least unless any other changes to the volume is performed.</p>
 <p>The contiguous file would have an advantage at time-critical read/write operations. It eliminates some overheads in the filesystem and the storage media caused by random access due to fragmented file data. Especially FAT access for the contiguous file on the exFAT volume is completely eliminated and storage media will be accessed sequentially.</p>
-<p>Also the contiguous file can be easily accessed directly via low-level disk functions. But this is not recommended in consideration for future compatibility.</p>
+<p>Also the contiguous file can be easily accessed directly via low-level disk functions. But this is not recommended in consideration for future compatibility. Use <a href="../res/app5.c">this function</a> to examine if the file is contiguous or not.</p>
 </div>
 
 <div class="para comp">

documents/doc/filename.html

@@ -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>

documents/doc/getcwd.html

@@ -50,7 +50,7 @@ FRESULT f_getcwd (
 
 <div class="para desc">
 <h4>Description</h4>
-<p>The <tt>f_getcwd</tt> function retrieves full path name of the current directory of the current drive. When <tt><a href="config.html#volumes">FF_VOLUMES</a> &gt;= 2</tt>, a heading drive prefix is added to the path name. The style of drive prefix is depends on <tt><a href="config.html#str_volume_id">FF_STR_VOLUME_ID</a></tt>.</p>
+<p>The <tt>f_getcwd</tt> function retrieves full path name of the current directory of the current drive. When <tt><a href="config.html#volumes">FF_VOLUMES</a> &gt;= 2</tt>, a heading drive prefix is added to the path name. The style of drive prefix depends on <tt><a href="config.html#str_volume_id">FF_STR_VOLUME_ID</a></tt>.</p>
 <p><em>Note: In this revision, this function cannot retrieve the current directory path on the exFAT volume. It always returns the root directory path.</em></p>
 </div>
 

documents/doc/open.html

@@ -118,7 +118,7 @@ int main (void)
     fr = <em>f_open</em>(&amp;fil, "message.txt", FA_READ);
     if (fr) return (int)fr;
 
-    <span class="c">/* Read all lines and display it */</span>
+    <span class="c">/* Read every line and display it */</span>
     while (f_gets(line, sizeof line, &amp;fil)) {
         printf(line);
     }
@@ -134,7 +134,7 @@ int main (void)
 
 int main (void)
 {
-    FATFS fs[2];         <span class="c">/* Work area (filesystem object) for logical drives */</span>
+    FATFS fs0, fs1;      <span class="c">/* Work area (filesystem object) for logical drives */</span>
     FIL fsrc, fdst;      <span class="c">/* File objects */</span>
     BYTE buffer[4096];   <span class="c">/* File copy buffer */</span>
     FRESULT fr;          <span class="c">/* FatFs function common result code */</span>
@@ -142,8 +142,8 @@ int main (void)
 
 
     <span class="c">/* Register work area for each logical drive */</span>
-    f_mount(&amp;fs[0], "0:", 0);
-    f_mount(&amp;fs[1], "1:", 0);
+    f_mount(&amp;fs0, "0:", 0);
+    f_mount(&amp;fs1, "1:", 0);
 
     <span class="c">/* Open source file on the drive 1 */</span>
     fr = <em>f_open</em>(&amp;fsrc, "1:file.bin", FA_READ);
@@ -166,8 +166,8 @@ int main (void)
     f_close(&amp;fdst);
 
     <span class="c">/* Unregister work area prior to discard it */</span>
-    f_mount(NULL, "0:", 0);
-    f_mount(NULL, "1:", 0);
+    f_mount(0, "0:", 0);
+    f_mount(0, "1:", 0);
 
     return (int)fr;
 }

documents/doc/rc.html

@@ -38,15 +38,15 @@ Note that if once this error occured at any operation to an open file, the file
 <li>No medium in the drive.</li>
 <li>Wrong lower layer implementation.</li>
 <li>Wrong hardware configuration.</li>
-<li>The storage device has been broken.</li>
+<li>The storage device has broken.</li>
 </ul>
 </dd>
 
 <dt id="nf">FR_NO_FILE</dt>
-<dd>Could not find the file.</dd>
+<dd>Could not find the file in the directory.</dd>
 
 <dt id="np">FR_NO_PATH</dt>
-<dd>Could not find the path.</dd>
+<dd>Could not find the path, some directory in the path name could not be found.</dd>
 
 <dt id="in">FR_INVALID_NAME</dt>
 <dd>The given string is invalid as the <a href="filename.html">path name</a>. One of the following possibilities is suspected.
@@ -72,12 +72,12 @@ Note that if once this error occured at any operation to an open file, the file
 </dd>
 
 <dt id="ex">FR_EXIST</dt>
-<dd>Name collision. An object with the same name is already existing.</dd>
+<dd>Name collision, an object with the same name is already existing.</dd>
 
 <dt id="io">FR_INVALID_OBJECT</dt>
 <dd>The file/directory object is invalid or a null pointer is given. There are some reasons as follows:
 <ul>
-<li>It has been closed, or collapsed.</li>
+<li>It has been closed, or the structure has been collapsed.</li>
 <li>It has been invalidated. Open objects on the volume are invalidated by voulme mount process.</li>
 <li>Physical drive is not ready to work due to a media removal.</li>
 </ul>

documents/doc/readdir.html

@@ -48,13 +48,13 @@ FRESULT f_readdir (
 
 <div class="para desc">
 <h4>Description</h4>
-<p>The <tt>f_readdir</tt> function reads a directory item, informations about the object. All items in the directory can be read in sequence by <tt>f_readdir</tt> function calls. Dot entries (<tt>"."</tt> and <tt>".."</tt>) in the sub-directory are filtered out and they will never appear in the read items. When all directory items have been read and no item to read, a nul string is stored into the <tt>fno-&gt;fname[]</tt> without any error. When a null pointer is given to the <tt class="arg">fno</tt>, the read index of the directory object is rewinded.</p>
+<p>The <tt>f_readdir</tt> function reads a directory item, informations about the object. Every item in the directory can be read in sequence by <tt>f_readdir</tt> function calls. Dot entries (<tt>"."</tt> and <tt>".."</tt>) in the sub-directory are filtered out and they will never appear in the read items. When all directory items have been read and no item to read, a null string is stored into the <tt>fno-&gt;fname[]</tt> without any error. When a null pointer is given to the <tt class="arg">fno</tt>, the read index of the directory object is rewinded.</p>
 <p>When support of long file name (LFN) is enabled, a member <tt>altname[]</tt> is defined in the file information structure to store the short file name of the object. If the long file name is not accessible due to some reason listed below, short file name is stored to the <tt>fname[]</tt> and <tt>altname[]</tt> has a null string.</p>
 <ul>
 <li>The item has no LFN. (Not the case at exFAT volume)</li>
 <li>Setting of <a href="config.html#max_lfn"><tt>FF_MAX_LFN</tt></a> is insufficient to handle the LFN. (Not the case at <tt>FF_MAX_LFN == 255</tt>)</li>
 <li>Setting of <a href="config.html#lfn_buf"><tt>FF_LFN_BUF</tt></a> is insufficient to store the LFN.</li>
-<li>The LFN contains any character not defined in current code page. (Not the case at <tt>FF_LFN_UNICODE &gt;= 1</tt>)</li>
+<li>The LFN contains some character not defined in current code page. (Not the case at <tt>FF_LFN_UNICODE &gt;= 1</tt>)</li>
 </ul>
 <p>There is a problem on reading a directory of exFAT volume. The exFAT does not support short file name. This means no name can be returned on the condition above. If it is the case, "?" is returned into the <tt>fname[]</tt> to indicate that the object is not accessible. To avoid this problem, configure FatFs <tt><a href="config.html#lfn_unicode">FF_LFN_UNICODE</a> &gt;= 1</tt> and <tt>FF_MAX_LFN == 255</tt> to support the full feature of LFN specification.</p>
 </div>

documents/doc/setlabel.html

@@ -53,9 +53,9 @@ FRESULT f_setlabel (
 <ul>
 <li>Up to 11 bytes long as conversion of OEM code page at FAT volume.</li>
 <li>Up to 11 characters long at exFAT volume.</li>
-<li>Allowable characters for FAT volume are: <tt>! # $ % &amp; ' ( ) - ^ _ ` ~ { } 0-9 A-Z a-z</tt> and extended characters. Low-case characters are up converted.</li>
-<li>Allowable characters for exFAT volume are: characters allowed for FAT volume and <tt>" + , . ; = [ ]</tt>. Low-case characters are preserved.</li>
-<li>Spaces can be contained anywhere in the volume label. Trailing spaces are truncated off at FAT volume.</li>
+<li>Allowable characters for FAT volume are: characters allowed for SFN excludes dot. Low-case characters are up converted.</li>
+<li>Allowable characters for exFAT volume are: characters allowed for LFN includes dot. Low-case characters are preserved.</li>
+<li>Spaces can be embedded anywhere in the volume label. Trailing spaces are truncated off at FAT volume.</li>
 </ul>
 <p>Remark: The standard system (Windows) has a problem at the volume label with a heading <tt>\xE5</tt> on the FAT volume. To avoid this problem, this function rejects such volume label as invalid name.</p>
 </div>

documents/doc/sync.html

@@ -44,7 +44,30 @@ FRESULT f_sync (
 
 <div class="para desc">
 <h4>Description</h4>
-<p>The <tt>f_sync</tt> function performs the same process as <tt>f_close</tt> function but the file is left opened and can continue read/write/seek operations to the file. This is suitable for the applications that open files for a long time in write mode, such as data logger. Performing <tt>f_sync</tt> function of periodic or immediataly after <tt>f_write</tt> function can minimize the risk of data loss due to a sudden blackout or an unintentional media removal. For more information, refer to <a href="appnote.html#critical">application note</a>.</p>
+<p>The <tt>f_sync</tt> function performs the same process as <tt>f_close</tt> function but the file is left opened and can continue read/write/seek operations to the file. This is suitable for the applications that open files for a long time in write mode, such as data logger. Performing <tt>f_sync</tt> function in certain interval can minimize the risk of data loss due to a sudden blackout or an unintentional media removal. For more information, refer to <a href="appnote.html#critical">application note</a>.</p>
+<pre>
+Case 1. Normal write sequence
+
+                                Time --&gt;                                     ↓Power off after close
+OwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwC
+
+
+Case 2. Without using f_sync()
+
+                                Time --&gt;                             ↓System crush
+O<span class="e">wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww</span>
+ |&lt;--------------- All data written will be lost ------------------&gt;|
+
+
+Case 3. Using f_sync()
+                                Time --&gt;                             ↓System crush
+OwwwwwwwwSwwwwwwwwSwwwwwwwwSwwwwwwwwSwwwwwwwwSwwwwwwwwSwwwwwwwwS<span class="e">wwwww</span>
+                            Data after last f_sync will be lost |&lt;-&gt;| 
+O - f_open()
+C - f_close()
+w - f_write()
+S - f_sync()
+</pre>
 <p>However there is no sense in <tt>f_sync</tt> function immediataly before <tt>f_close</tt> function because it performs <tt>f_sync</tt> function in it. In other words, the differnce between those functions is that the file object is invalidated or not.</p>
 </div>
 

documents/doc/unlink.html

@@ -13,7 +13,7 @@
 
 <div class="para func">
 <h2>f_unlink</h2>
-<p>The f_unlink function removes a file or sub-directory.</p>
+<p>The f_unlink function removes a file or sub-directory from the volume.</p>
 <pre>
 FRESULT f_unlink (
   const TCHAR* <span class="arg">path</span>  <span class="c">/* [IN] Object name */</span>

documents/res/app2.c

@@ -1,65 +1,78 @@
 /*------------------------------------------------------------/
-/ Remove all contents of a directory
-/ This function works regardless of FF_FS_RPATH.
-/------------------------------------------------------------*/
+/ Delete a sub-directory even if it contains any file
+/-------------------------------------------------------------/
+/ The delete_node() function is for R0.12+.
+/ It works regardless of FF_FS_RPATH.
+*/
 
 
-FILINFO fno;
-
-FRESULT empty_directory (
-    char* path      /* Working buffer filled with start directory */
+FRESULT delete_node (
+    TCHAR* path,    /* Path name buffer with the sub-directory to delete */
+    UINT sz_buff,   /* Size of path name buffer (items) */
+    FILINFO* fno    /* Name read buffer */
 )
 {
     UINT i, j;
     FRESULT fr;
     DIR dir;
 
-    fr = f_opendir(&dir, path);
-    if (fr == FR_OK) {
-        for (i = 0; path[i]; i++) ;
-        path[i++] = '/';
-        for (;;) {
-            fr = f_readdir(&dir, &fno);
-            if (fr != FR_OK || !fno.fname[0]) break;
-            if (_FS_RPATH && fno.fname[0] == '.') continue;
-            j = 0;
-            do
-                path[i+j] = fno.fname[j];
-            while (fno.fname[j++]);
-            if (fno.fattrib & AM_DIR) {
-                fr = empty_directory(path);
-                if (fr != FR_OK) break;
+
+    fr = f_opendir(&dir, path); /* Open the sub-directory to make it empty */
+    if (fr != FR_OK) return fr;
+
+    for (i = 0; path[i]; i++) ; /* Get current path length */
+    path[i++] = _T('/');
+
+    for (;;) {
+        fr = f_readdir(&dir, fno);  /* Get a directory item */
+        if (fr != FR_OK || !fno->fname[0]) break;   /* End of directory? */
+        j = 0;
+        do {    /* Make a path name */
+            if (i + j >= sz_buff) { /* Buffer over flow? */
+                fr = 100; break;    /* Fails with 100 when buffer overflow */
             }
+            path[i + j] = fno->fname[j];
+        } while (fno->fname[j++]);
+        if (fno->fattrib & AM_DIR) {    /* Item is a sub-directory */
+            fr = delete_node(path, sz_buff, fno);
+        } else {                        /* Item is a file */
             fr = f_unlink(path);
-            if (fr != FR_OK) break;
         }
-        path[--i] = '\0';
-        closedir(&dir);
+        if (fr != FR_OK) break;
     }
 
+    path[--i] = 0;  /* Restore the path name */
+    f_closedir(&dir);
+
+    if (fr == FR_OK) fr = f_unlink(path);  /* Delete the empty sub-directory */
     return fr;
 }
 
 
 
-int main (void)
+
+int main (void) /* How to use */
 {
     FRESULT fr;
     FATFS fs;
-    char buff[256];    /* Working buffer */
+    TCHAR buff[256];
+    FILINFO fno;
 
 
+    f_mount(&fs, _T("5:"), 0);
 
-    f_mount(&fs, "", 0);
+    /* Directory to be deleted */
+    _tcscpy(buff, _T("5:dir"));
 
-    strcpy(buff, "/");  /* Directory to be emptied */
-    fr = empty_directory(buff);
+    /* Delete the directory */
+    fr = delete_node(buff, sizeof buff / sizeof buff[0], &fno);
 
+    /* Check the result */
     if (fr) {
-        printf("Function failed. (%u)\n", fr);
+        _tprintf(_T("Failed to delete the directory. (%u)\n"), fr);
         return fr;
     } else {
-        printf("All contents in the %s are successfully removed.\n", buff);
+        _tprintf(_T("The directory and the contents have successfully been deleted.\n"), buff);
         return 0;
     }
 }

documents/res/app5.c

@@ -0,0 +1,38 @@
+/*----------------------------------------------------------------------/
+/ Test if the file is contiguous                                        /
+/----------------------------------------------------------------------*/
+
+FRESULT test_contiguous_file (
+    FIL* fp,    /* [IN]  Open file object to be checked */
+    int* cont   /* [OUT] 1:Contiguous, 0:Fragmented or zero-length */
+)
+{
+    DWORD clst, clsz, step;
+    FSIZE_t fsz;
+    FRESULT fr;
+
+
+    *cont = 0;
+    fr = f_lseek(fp, 0);            /* Validates and prepares the file */
+    if (fr != FR_OK) return fr;
+
+#if FF_MAX_SS == FF_MIN_SS
+    clsz = (DWORD)fp->obj.fs->csize * FF_MAX_SS;    /* Cluster size */
+#else
+    clsz = (DWORD)fp->obj.fs->csize * fp->obj.fs->ssize;
+#endif
+    fsz = fp->obj.objsize;
+    if (fsz > 0) {
+        clst = fp->obj.sclust - 1;  /* A cluster leading the first cluster for first test */
+        while (fsz) {
+            step = (fsz >= clsz) ? clsz : (DWORD)fsz;
+            fr = f_lseek(fp, f_tell(fp) + step);    /* Advances file pointer a cluster */
+            if (fr != FR_OK) return fr;
+            if (clst + 1 != fp->clust) break;       /* Is not the cluster next to previous one? */
+            clst = fp->clust; fsz -= step;          /* Get current cluster for next test */
+        }
+        if (fsz == 0) *cont = 1;    /* All done without fail? */
+    }
+
+    return FR_OK;
+}

documents/updates.txt

@@ -1,6 +1,12 @@
+R0.13c (October 14, 2018)
+  Supported stdint.h for C99 and later. (integer.h was included in ff.h)
+  Fixed reading a directory gets infinite loop when the last directory entry is not empty. (appeared at R0.12)
+  Fixed creating a sub-directory in the fragmented sub-directory on the exFAT volume collapses FAT chain of the parent directory. (appeared at R0.12)
+  Fixed f_getcwd() cause output buffer overrun when the buffer has a valid drive number. (appeared at R0.13b)
+
 R0.13b (April 07, 2018)
   Added support for UTF-32 encoding on the API. (FF_LFN_UNICODE = 3)
-  Added support for Unix style volume ID. (FF_STR_VOLUME_ID = 2)
+  Added support for Unix style volume prefix. (FF_STR_VOLUME_ID = 2)
   Fixed accesing any object on the exFAT root directory beyond the cluster boundary can fail. (appeared at R0.12c)
   Fixed f_setlabel() does not reject some invalid characters. (appeared at R0.09b)