file This module provides an interface to the file system. Warning: File operations are only guaranteed to appear atomic when going through the same file server. A NIF or other OS process may observe intermediate steps on certain operations on some operating systems, eg. renaming an existing file on Windows, or write_file_info/2 on any OS at the time of writing. Regarding filename encoding, the Erlang VM can operate in two modes. The current mode can be queried using function  native_name_encoding/0. It returns latin1 or utf8. In latin1 mode, the Erlang VM does not change the encoding of filenames. In utf8 mode, filenames can contain Unicode characters greater than 255 and the VM converts filenames back and forth to the native filename encoding (usually UTF-8, but UTF-16 on Windows). The default mode depends on the operating system. Windows, MacOS X and Android enforce consistent filename encoding and therefore the VM uses utf8 mode. On operating systems with transparent naming (for example, all Unix systems except MacOS X), default is utf8 if the terminal supports UTF-8, otherwise latin1. The default can be overridden using +fnl (to force latin1 mode) or +fnu (to force utf8 mode) when starting erl. On operating systems with transparent naming, files can be inconsistently named, for example, some files are encoded in UTF-8 while others are encoded in ISO Latin-1. The concept of raw filenames is introduced to handle file systems with inconsistent naming when running in utf8 mode. A raw filename is a filename specified as a binary. The Erlang VM does not translate a filename specified as a binary on systems with transparent naming. When running in utf8 mode, functions list_dir/1 and  read_link/1 never return raw filenames. To return all filenames including raw filenames, use functions list_dir_all/1 and  read_link_all/1. See also section Notes About Raw Filenames in the STDLIB User's Guide. Note: File operations used to accept filenames containing null characters (integer value zero). This caused the name to be truncated and in some cases arguments to primitive operations to be mixed up. Filenames containing null characters inside the filename are now rejected and will cause primitive file operations fail. POSIX Error Codes • eacces - Permission denied • eagain - Resource temporarily unavailable • ebadf - Bad file number • ebusy - File busy • edquot - Disk quota exceeded • eexist - File already exists • efault - Bad address in system call argument • efbig - File too large • eintr - Interrupted system call • einval - Invalid argument • eio - I/O error • eisdir - Illegal operation on a directory • eloop - Too many levels of symbolic links • emfile - Too many open files • emlink - Too many links • enametoolong - Filename too long • enfile - File table overflow • enodev - No such device • enoent - No such file or directory • enomem - Not enough memory • enospc - No space left on device • enotblk - Block device required • enotdir - Not a directory • enotsup - Operation not supported • enxio - No such device or address • eperm - Not owner • epipe - Broken pipe • erofs - Read-only file system • espipe - Invalid seek • esrch - No such process • estale - Stale remote file handle • exdev - Cross-domain link Performance For increased performance, raw files are recommended. A normal file is really a process so it can be used as an I/O device (see io). Therefore, when data is written to a normal file, the sending of the data to the file process, copies all data that are not binaries. Opening the file in binary mode and writing binaries is therefore recommended. If the file is opened on another node, or if the file server runs as slave to the file server of another node, also binaries are copied. Note: Raw files use the file system of the host machine of the node. For normal files (non-raw), the file server is used to find the files, and if the node is running its file server as slave to the file server of another node, and the other node runs on some other host machine, they can have different file systems. However, this is seldom a problem. open/2 can be given the options delayed_write and read_ahead to turn on caching, which will reduce the number of operating system calls and greatly improve performance for small reads and writes. However, the overhead won't disappear completely and it's best to keep the number of file operations to a minimum. As a contrived example, the following function writes 4MB in 2.5 seconds when tested: create_file_slow(Name) -> {ok, Fd} = file:open(Name, [raw, write, delayed_write, binary]), create_file_slow_1(Fd, 4 bsl 20), file:close(Fd). create_file_slow_1(_Fd, 0) -> ok; create_file_slow_1(Fd, M) -> ok = file:write(Fd, <<0>>), create_file_slow_1(Fd, M - 1). The following functionally equivalent code writes 128 bytes per call to write/2 and so does the same work in 0.08 seconds, which is roughly 30 times faster: create_file(Name) -> {ok, Fd} = file:open(Name, [raw, write, delayed_write, binary]), create_file_1(Fd, 4 bsl 20), file:close(Fd), ok. create_file_1(_Fd, 0) -> ok; create_file_1(Fd, M) when M >= 128 -> ok = file:write(Fd, <<0:(128)/unit:8>>), create_file_1(Fd, M - 128); create_file_1(Fd, M) -> ok = file:write(Fd, <<0:(M)/unit:8>>), create_file_1(Fd, M - 1). When writing data it's generally more efficient to write a list of binaries rather than a list of integers. It is not needed to flatten a deep list before writing. On Unix hosts, scatter output, which writes a set of buffers in one operation, is used when possible. In this way write(FD, [Bin1, Bin2 | Bin3]) writes the contents of the binaries without copying the data at all, except for perhaps deep down in the operating system kernel. Warning: If an error occurs when accessing an open file with module io, the process handling the file exits. The dead file process can hang if a process tries to access it later. This will be fixed in a future release. See Also filename(3)