Contact emails [email protected]
Explainer https://github.com/a-sully/fs/pull/1 Specification https://github.com/whatwg/fs/pull/9 Summary Currently, it is not possible to remove a file or directory given its handle. You must obtain the handle of the parent directory and call FileSystemDirectoryHandle::removeEntry(). Introducing a new method, FileSystemHandle::remove(), enables the common use case where you obtain a file handle from showSaveFilePicker(), but then decide you don't want to save after all, and delete the file. Blink component Blink>Storage>FileSystem <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage%3EFileSystem> TAG review https://github.com/w3ctag/design-reviews/issues/773 TAG review status Pending Risks Interoperability and Compatibility Gecko: No signal (yet - https://github.com/mozilla/standards-positions/issues/716) WebKit: Positive (https://github.com/WebKit/standards-positions/issues/104) Web developers: Positive ( https://github.com/WICG/file-system-access/issues/214) Also https://crbug.com/1114923 Ergonomics This will significantly improve the ergonomics of the API <https://github.com/a-sully/fs/blob/6abfb840112d137c22fbf0fb986471dfe63a89fc/Remove.md#improve-ergonomics-of-the-api> . Currently, if a file handle is obtained via the showSaveFilePicker() API, the site has no way to remove the file if the user changes their mind and wants the file deleted, leaving the file system in an awkward state. The remove() method fills this gap. Security Files and directories will only be removable if the user has explicitly granted read/write access to the handle. This method will take an exclusive read/write lock to the file. It's possible that the file is locked by another site (e.g. if the site has an open FileSystemWritableFileStream to the file). In this case, the remove() operation will fail with a locking error. The site is aware that the file is locked, but it does not know how or by whom. This is not a concern. WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? N/A Debuggability N/A Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? Yes - currently in WICG/file-system-access <https://wpt.fyi/results/file-system-access?label=master&label=experimental&aligned&view=subtest&q=remove> but will be moved to whatwg/fs <https://wpt.fyi/results/fs?label=experimental&label=master&aligned> upon approval Flag name FileSystemAccessAPIExperimental Requires code in //chrome? False Tracking bug https://crbug.com/1114923 Estimated milestones Shipping in M110 Anticipated spec changes https://github.com/whatwg/fs/pull/9 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/6318478849998848 This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- Austin Sullivan | Software Engineer | [email protected] -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnvaEUqGEfUwzgNgzNhZg_i_Q0O0RYXjoC9e1XCheVRZoSTHg%40mail.gmail.com.
