https://github.com/whatwg/fs/pull/9
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.
NOTE: The code for this already landed behind a flag; we're filing this I2P retroactively.
https://github.com/w3ctag/design-reviews/issues/773
Pending
Gecko: Positive (https://github.com/WICG/file-system-access/pull/283#issuecomment-1036085470)
WebKit: No signal
Web developers: Positive (https://github.com/WICG/file-system-access/issues/214). Also https://crbug.com/1114923
Other signals:
This will improve the 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.
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.
N/A
No. The File System Access API is not yet supported on Android (tracking bug)
Yes (link)
FileSystemAccessAPIExperimental
False
https://chromestatus.com/feature/6318478849998848
This intent message was generated by Chrome Platform Status.