The File System API is an abandoned API intending to allow manipulating files and directories in a *virtualized* file system stored by the browser in a sandboxed area of the client system.
IMPORTANT: In April 2014, it was announced on public-webapps that the Filesystem API spec should be considered "clearly dead," as browsers have shown little interest in implementing it.
The File System API simulates a sandboxed virtualized file system that can be used to manipulate files and directories.
In spite of its name, the File System API cannot directly access the local file system. This is probably the most misunderstood aspect (and commonly asked question) about this API. For example, the API cannot be used to GetFile('C:\Users\Public\Desktop\foobar.txt')
from the client file system. Likewise, the API cannot write directly to the client file system.
When writing data to the local system, web clients (browsers) do not locally store files according to their (virtual) file names as created in the script. Creating a file named "login.txt" in the API does not cause the client to store a real file called "login.txt" on the local file system. Google Chrome, for example, will only store a numerically named file (e.g., "00004") in a directory dedicated to sandboxed storage on the client device. Therefore the File System API cannot be used to write to the local file system in any way intended for external/outside access to the sandboxed storage area. In some environments, best practices for secure coding may prohibit the persistent storage of sensitive data through the File System API, as malicious code running locally on the host machine may gain access to the sandboxed storage area.
To prevent local storage of malicious code, the API prohibits storage of executable files (such as .exe files) in the virtualized file system.
See Also
- MDN: File System API
- HTML5 Rocks: Exploring the Filesystem APIs
- Specification: File API: Directories and System
- fileapi (not to be confused with html5-filesystem)