Add documentation about raw filenames and Unicode file name translation mode

1 files changed, 71 insertions, 1 deletions

diff --git a/lib/kernel/doc/src/file.xml b/lib/kernel/doc/src/file.xml
index 64cdd3a8ea..d3441d3623 100644
--- a/lib/kernel/doc/src/file.xml
+++ b/lib/kernel/doc/src/file.xml
@@ -36,6 +36,61 @@
       other Erlang processes to continue executing in parallel with
       the file operations. See the command line flag
       <c>+A</c> in <seealso marker="erts:erl">erl(1)</seealso>.</p>
+
+    <p>The Erlang VM supports file names in Unicode to a limited
+    extent.  Depending on how the VM is started (with the parameter
+    <c>+fnu</c> or <c>+fnl</c>), file names given can contain
+    characters > 255 and the VM system will convert file names
+    back and forth to the native file name encoding.</p>
+
+    <p>The default behavior for Unicode character translation depends
+    on to what extent the underlying OS/filesystem enforces consistent
+    naming. On OSes where all file names are ensured to be in one or
+    another encoding, Unicode is the default (currently this holds for
+    Windows and MacOSX). On OSes with completely transparent file
+    naming (i.e. all Unixes except MacOSX), ISO-latin-1 file naming is
+    the default. The reason for the ISO-latin-1 default is that
+    file names are not guaranteed to be possible to interpret according to
+    the Unicode encoding expected (i.e. UTF-8), and file names that
+    cannot be decoded will only be accessible by using &quot;raw
+    file names&quot;, in other word file names given as binaries.</p>
+ 
+    <p>As file names are traditionally not binaries in Erlang,
+    applications that need to handle raw file names need to be
+    converted, why the Unicode mode for file names is not default on
+    systems having completely transparent file naming.</p>
+
+    <note>As of R14B01, the most basic file handling modules
+    (<c>file</c>, <c>prim_file</c>, <c>filelib</c> and
+    <c>filename</c>) accept raw file names, but the rest of OTP is not
+    guaranteed to handle them, why Unicode file naming on systems
+    where it is not default is still considered experimental.</note>
+
+    <p>Raw file names is a new feature in OTP R14B01, which allows the
+    user to supply completely uninterpreted file names to the
+    underlying OS/filesystem. They are supplied as binaries, where it
+    is up to the user to supply a correct encoding for the
+    environment. The function <c>file:native_name_encoding()</c> can
+    be used to check what encoding the VM is working in. If the
+    function returns <c>latin1</c> file names are not in any way
+    converted to Unicode, if it is <c>utf8</c>, raw file names should
+    be encoded as UTF-8 if they are to follow the convention of the VM
+    (and usually the convention of the OS as well). Using raw
+    file names is useful if you have a filesystem with inconsistent
+    file naming, where some files are named in UTF-8 encoding while
+    others are not. A file:list_dir on such mixed file name systems
+    when the VM is in Unicode file name mode might return file names as
+    raw binaries as they cannot be interpreted as Unicode
+    file names. Raw file names can also be used to give UTF-8 encoded
+    file names even though the VM is not started in Unicode file name
+    translation mode.</p>
+
+    <p>Note that on Windows, <c>file:native_name_encoding()</c>
+    returns <c>utf8</c> per default, which is the format for raw
+    file names even on Windows, although the underlying OS specific
+    code works in a limited version of little endian UTF16. As far as
+    the Erlang programmer is concerned, Windows native Unicode format
+    is UTF-8...</p>
   </description>
 
   <section>
@@ -47,8 +102,14 @@ iodata() = iolist() | binary()
 io_device()
   as returned by file:open/2, a process handling IO protocols
 
-name() = string() | atom() | DeepList
+name() = string() | atom() | DeepList | RawFilename
   DeepList = [char() | atom() | DeepList]
+  RawFilename = binary()
+  If VM is in unicode filename mode, string() and char() are allowed to be > 255.
+  RawFilename is a filename not subject to Unicode translation, meaning that it 
+  can contain characters not conforming to the Unicode encoding expected from the 
+  filesystem (i.e. non-UTF-8 characters although the VM is started in Unicode 
+  filename mode).
 
 posix()
   an atom which is named from the POSIX error codes used in
@@ -598,6 +659,15 @@ f.txt:  {person, "kalle", 25}.
       </desc>
     </func>
     <func>
+      <name>native_name_encoding() -> latin1 | utf8</name>
+      <fsummary>Retunr the VMs configure filename encoding.</fsummary>
+      <desc>
+        <p>This function returns the configured default file name encoding to use for raw file names. Generally an application supplying file names raw (as binaries), should obey the character encoding returned by this function.</p>
+	<p>By default, the VM uses ISO-latin-1 file name encoding on filesystems and/or OSes that use completely transparent file naming. This includes all Unix versions except for MacOSX, where the vfs layer enforces UTF-8 file naming. By giving the experimental option <c>+fnu</c> when starting Erlang, UTF-8 translation of file names can be turned on even for those systems. If Unicode file name translation is in effect, the system behaves as usual as long as file names conform to the encoding, but will return file names that are not properly encoded in UTF-8 as raw file names (i.e. binaries).</p> 
+	<p>On Windows, this function also returns <c>utf8</c> by default. The OS uses a pure Unicode naming scheme and file names are always possible to interpret as valid Unicode. The fact that the underlying Windows OS actually encodes file names using little endian UTF-16 can be ignored by the Erlang programmer. Windows and MacOSX are the only operating systems where the VM operates in Unicode file name mode by default.</p>
+      </desc>
+    </func>
+    <func>
       <name>open(Filename, Modes) -> {ok, IoDevice} | {error, Reason}</name>
       <fsummary>Open a file</fsummary>
       <type>