1# FileSystem API 2 3This directory contains the renderer side implementation of various filesystem 4related APIs. 5 6## Related directories 7 8[`//storage/browser/file_system/`](../../../storage/browser/file_system) contains part 9of the browser side implementation, while 10[`//content/browser/fileapi/`](../../../content/browser/fileapi) contains the 11rest of the browser side implementation and 12[`blink/public/mojom/filesystem`](../../../third_party/blink/public/mojom/filesystem) 13contains the mojom interfaces for these APIs. 14 15## APIs In this directory 16 17### File and Directory Entries API 18 19First of all this directory contains the implementation of the 20[Entries API](https://wicg.github.io/entries-api). This API consists of 21types to expose read-only access to file and directory entries to the web, 22primarily used by drag-and-drop and `<input type=file>`. Our implementation 23doesn't match the interface names of the spec, but otherwise should be pretty 24close to the spec. 25 26TODO(mek): More details 27 28### File API: Directories and FileSystem 29 30Secondly this directory contains the implementation of something similar to the 31deprecated [w3c file-system-api](https://www.w3.org/TR/2012/WD-file-system-api-20120417/). 32This API is very similar to the previous Entries API, but it also adds support 33for writing and modifying to files and directories, as well as a way to get 34access to a origin scoped sandboxed filesystem. 35 36TODO(mek): More details 37 38### Writable Files 39 40Finally this directory contains the implementation of the new and still under 41development [Writable Files API](https://github.com/WICG/writable-files/blob/master/EXPLAINER.md). 42This API is mostly implemented on top of the same backend as the previous two 43APIs, but hopes to eventually replace both of those, while also adding new 44functionality. 45 46It consists of the following parts: 47 48 * `FileSystemBaseHandle`, `FileSystemFileHandle` and `FileSystemDirectoryHandle`: 49 these interfaces mimic the old `Entry` interfaces (and inherit from `EntryBase` 50 to share as much of the implementation as possible), but expose a more modern 51 promisified API. 52 53 * `getSystemDirectory`: An entry point (exposed via `FileSystemDirectoryHandle`) 54 that today only gives access to the same sandboxed filesystem as what was 55 available through the old API. In the future this could get extended to add 56 support for other directories as well. 57 58 * `FileSystemWriter`: a more modern API with similar functionality to the 59 old `FileWriter` API. The implementation of this actually does make use of 60 a different mojom interface than the old API. But since the functionality is 61 mostly the same, hopefully we will be able to migrate the old implementation 62 to the new mojom API as well. 63 64 * `chooseFileSystemEntries`: An entry point, currently on `window`, that lets 65 a website pop-up a file picker, prompting the user to select one or more 66 files or directories, to which the website than gets access. 67 68Since the `Handle` interfaces are based on the implementation of the `Entry` 69interfaces, internally and across IPC these are still represented by 70`filesystem://` URLs. Hopefully in the future we will be able to change this and 71turn it into a more capabilities based API (where having a mojo handle gives you 72access to specific files or directories), as with the current implementation it 73is very hard to properly support transferring handles to other processes via 74postMessage (which is something we do want to support in the future). 75