We're planning to deprecate/remove.

Spec is https://www.w3.org/TR/file-system-api/ (older versions have actual content)

Just to clarify, we are planning to remove entire FileSystem APIs? 
Thanks

It's complicated.

Parts are used for drag and drop, which is getting implemented by other browser vendors which copied parts of the API. Newer spec at:  https://wicg.github.io/entries-api/

Apps/Extensions and other Chrome-specific things (e.g. parts of ChromeOS) use the FS API as well, which we can't remove. But there's a web-exposed subset we'd like to remove; we need to start with data gathering to see if it's feasible. (Initial investigation showed it was, but we need more data to proceed.)

I can provide more background, context, and current motivation offline if desired. 

jsbell@, could you tweak the title of this bug to pin down the bits of API surface that are still not in any spec?

webkitRequestFileSystem and webkitResolveLocalFileSystem aren't mentioned in https://wicg.github.io/entries-api/, but are the more bits?

Oops, webkitResolveLocalFileSystemURL

I'm not entirely sure what you need. Can you clarify?

requestFileSystem and resolveLocalFileSystem are from:

https://www.w3.org/TR/2012/WD-file-system-api-20120417/#obtaining-access-to-file-system-entry-points

Do you just want (webkitRequestFileSystem, webkitResolveLocalFileSystem) to be appended to the title?

Workers also have requestFileSystemSync and resolveLocalFileSystemSyncURL (but prefixed of course)

Also for DedicatedWorkerGlobalScope and SharedWorkerGlobalScope:
webkitRequestFileSystem
webkitRequestFileSystemSync
webkitResolveLocalFileSystemSyncURL
webkitResolveLocalFileSystemURL

Are we planning to remove those as well?

Yes.

Emphasis on "planning" - there's a lot of work ahead to pull this off.

 Issue 695582  has been merged into this issue.

Just enumerating the API surface I think is involved here, correct me if I'm mistaken:
 * webkitRequestFileSystem and webkitResolveLocalFileSystemURL in window and workers
 * TEMPORARY and TEMPORARY constants on window and workers
 * webkitRequestFileSystemSync and webkitResolveLocalFileSystemSyncURL in workers
 * FileSystemCallback callback interface
 * DOMFileSystem interface (has NoInterfaceObject)

DOMFileSystem has gotten new life via https://wicg.github.io/entries-api/ albeit with a different name. For code/types that are shared between the non-cross-browser filesystem API and the now cross-browser file/directory entries API I'm still not sure if it will be easiest to rename what's in there now or make a copy.

Thanks Josh! If anyone searches for DOMFileSystem and finds comment #12, do not be alarmed! :)

Does what remain make sense as a single package of work?

Yes.

What is the motivation for this?

#17: Other browser vendors have not implemented this API, and are not interested in implementing it, so the API has failed to gain traction. Furthermore, this API adds a non-trivial maintenance burden to Chrome developers.

Are you asking out of curiosity, or do you have an impacted application?

Is Chrome interested in implementing the newer filesystem spec at w3c.github.io/filesystem-api, or skeptical of the usefulness of a sandboxed filesystem api in general?

I believe a filesystem abstraction could be created using the Indexed Database api, with everything except filesystem URLs, which would cover my use cases, though not as efficiently.

#19: Perhaps you can use the polyfill below to get off the filesystem API? 

https://github.com/ebidel/idb.filesystem.js/

There are many use cases that we'd like to enable for Web apps where a sandbox filesystem doesn't cut it. That being said, we're still figuring out what we'd like to do in this space.

For searchability, I'll throw in that since this tracks removing webkitRequestFileSystemSync, by extension that also covers these interfaces:

DOMFileSystemSync
DirectoryEntrySync
DirectoryReaderSync
EntrySync
FileEntrySync
FileReaderSync
FileWriterSync

Is that right?

How about these methods on Entry.idl, are they in scope of this bug?

getMetadata()
moveTo()
copyTo()
toURL()
remove()

https://wicg.github.io/entries-api/#api-entry has getParent()

All correct.

Also: 

DirectoryEntry.removeRecursively()
FileEntry.createWriter()
MetadataCallback
FileWriterCallback

Thanks! Just trying to figure out which bits of non-standard IDL to link back to this :)