tree: d2d049660c1e424fe83f3c297aa88ebebcaa0a98 [path history] [tgz]
  1. BUILD.gn
  2. choose_file_system_entries_options.idl
  3. choose_file_system_entries_options_accepts.idl
  4. data_transfer_item_file_system.cc
  5. data_transfer_item_file_system.h
  6. data_transfer_item_file_system.idl
  7. dedicated_worker_global_scope_file_system.idl
  8. DEPS
  9. dev_tools_host_file_system.cc
  10. dev_tools_host_file_system.h
  11. dev_tools_host_file_system.idl
  12. directory_entry.cc
  13. directory_entry.h
  14. directory_entry.idl
  15. directory_entry_sync.cc
  16. directory_entry_sync.h
  17. directory_entry_sync.idl
  18. directory_reader.cc
  19. directory_reader.h
  20. directory_reader.idl
  21. directory_reader_base.h
  22. directory_reader_sync.cc
  23. directory_reader_sync.h
  24. directory_reader_sync.idl
  25. dom_file_path.cc
  26. dom_file_path.h
  27. dom_file_system.cc
  28. dom_file_system.h
  29. dom_file_system.idl
  30. dom_file_system_base.cc
  31. dom_file_system_base.h
  32. dom_file_system_base_test.cc
  33. dom_file_system_sync.cc
  34. dom_file_system_sync.h
  35. dom_file_system_sync.idl
  36. dom_window_file_system.cc
  37. dom_window_file_system.h
  38. dragged_isolated_file_system_impl.cc
  39. dragged_isolated_file_system_impl.h
  40. entries_callback.idl
  41. entry.cc
  42. entry.h
  43. entry.idl
  44. entry_base.cc
  45. entry_base.h
  46. entry_callback.idl
  47. entry_heap_vector.h
  48. entry_sync.cc
  49. entry_sync.h
  50. entry_sync.idl
  51. error_callback.idl
  52. file_callback.idl
  53. file_entry.cc
  54. file_entry.h
  55. file_entry.idl
  56. file_entry_sync.cc
  57. file_entry_sync.h
  58. file_entry_sync.idl
  59. file_system_base_handle.cc
  60. file_system_base_handle.h
  61. file_system_base_handle.idl
  62. file_system_callback.idl
  63. file_system_callbacks.cc
  64. file_system_callbacks.h
  65. file_system_client.h
  66. file_system_directory_handle.cc
  67. file_system_directory_handle.h
  68. file_system_directory_handle.idl
  69. file_system_directory_iterator.cc
  70. file_system_directory_iterator.h
  71. file_system_directory_iterator.idl
  72. file_system_directory_iterator_entry.idl
  73. file_system_dispatcher.cc
  74. file_system_dispatcher.h
  75. file_system_file_handle.cc
  76. file_system_file_handle.h
  77. file_system_file_handle.idl
  78. file_system_flags.idl
  79. file_system_get_directory_options.idl
  80. file_system_get_file_options.idl
  81. file_system_writer.cc
  82. file_system_writer.h
  83. file_system_writer.idl
  84. file_writer.cc
  85. file_writer.h
  86. file_writer.idl
  87. file_writer_base.cc
  88. file_writer_base.h
  89. file_writer_callback.idl
  90. file_writer_sync.cc
  91. file_writer_sync.h
  92. file_writer_sync.idl
  93. file_writer_test.cc
  94. get_system_directory_options.idl
  95. html_input_element_file_system.cc
  96. html_input_element_file_system.h
  97. html_input_element_file_system.idl
  98. local_file_system.cc
  99. local_file_system.h
  100. local_file_system_client.cc
  101. local_file_system_client.h
  102. metadata.h
  103. metadata.idl
  104. metadata_callback.idl
  105. OWNERS
  106. README.md
  107. shared_worker_global_scope_file_system.idl
  108. sync_callback_helper.h
  109. window_file_system.idl
  110. worker_global_scope_file_system.cc
  111. worker_global_scope_file_system.h
third_party/blink/renderer/modules/filesystem/README.md

FileSystem API

This directory contains the renderer side implementation of various filesystem related APIs.

Related directories

//storage/browser/fileapi/ contains part of the browser side implementation, while //content/browser/fileapi/ contains the rest of the browser side implementation and blink/public/mojom/filesystem contains the mojom interfaces for these APIs.

APIs In this directory

File and Directory Entries API

First of all this directory contains the implementation of the Entries API. This API consists of types to expose read-only access to file and directory entries to the web, primarily used by drag-and-drop and <input type=file>. Our implementation doesn't match the interface names of the spec, but otherwise should be pretty close to the spec.

TODO(mek): More details

File API: Directories and FileSystem

Secondly this directory contains the implementation of something similar to the deprecated w3c file-system-api. This API is very similar to the previous Entries API, but it also adds support for writing and modifying to files and directories, as well as a way to get access to a origin scoped sandboxed filesystem.

TODO(mek): More details

Writable Files

Finally this directory contains the implementation of the new and still under development Writable Files API. This API is mostly implemented on top of the same backend as the previous two APIs, but hopes to eventually replace both of those, while also adding new functionality.

It consists of the following parts:

  • FileSystemBaseHandle, FileSystemFileHandle and FileSystemDirectoryHandle: these interfaces mimic the old Entry interfaces (and inherit from EntryBase to share as much of the implementation as possible), but expose a more modern promisified API.

  • getSystemDirectory: An entry point (exposed via FileSystemDirectoryHandle) that today only gives access to the same sandboxed filesystem as what was available through the old API. In the future this could get extended to add support for other directories as well.

  • FileSystemWriter: a more modern API with similar functionality to the old FileWriter API. The implementation of this actually does make use of a different mojom interface than the old API. But since the functionality is mostly the same, hopefully we will be able to migrate the old implementation to the new mojom API as well.

  • chooseFileSystemEntries: An entry point, currently on window, that lets a website pop-up a file picker, prompting the user to select one or more files or directories, to which the website than gets access.

Since the Handle interfaces are based on the implementation of the Entry interfaces, internally and across IPC these are still represented by filesystem:// URLs. Hopefully in the future we will be able to change this and turn it into a more capabilities based API (where having a mojo handle gives you access to specific files or directories), as with the current implementation it is very hard to properly support transferring handles to other processes via postMessage (which is something we do want to support in the future).