perhaps maybe to restrictive?

[jimmywarting]

I find the directory picker to be maybe to picky on what i can and can't choose b/c it can contain executable or system files?

Maybe instead of flat out restricting me to pick any folder i want how about instead allowing showDirectoryPicker to succeed on mostly anything and instead make the read, write, requestPermission access on that handle to throw instead? it would be like creating some opaque handle that you would not be able to do much with it.

In that case maybe you can at least go into some some of the directory or read some of the file or allowing anyone do save multiple files in a newly created directory, it feels quite silly that i can't select the nearly empty download folder to save multiple files which i can't select, But i can select my hole git folder where i have a buch of bad voodoo stuff that can execute a bunch of things, like what gives?

if i could pick the download folder (that i'm not able to select for some unknown reason) an i get a directory handle, then if i create a new folder within that directory and do: downloadDirHandle.getDirectoryHandle('status-report-${Date.now()}', { create: true }) then surly that newly created folder should at least be safe to read and write files to?

[jimmywarting]

Some years ago I create a daisydisk like application entirely built in the web that won't require you to download any application (thanks to drag and drop to asynchronous read the content the chosen directory that you picked)

here is a demo of it: https://jimmywarting.github.io/diezyweb/ and the source too
At least this dose not require any read or write access, All it really needs is some metadata about file size, that's all...

i think it's mostly thanks to entry.getMetadata() that whatwg/fs is missing. I would like revive/modernize this and do something more useful with this now that we have the whatwg/fs but i think the old api still beats this new whatwg/fs in terms of easy access and speed, i don't think promises and filehandle.getFile() would make it any faster. i bet the older api with drag and drop still beats the new fs api

I mean i can drag and drop almost any folder i want into the browser but i can't select it with show showDirectoryPicker - that is a bit odd... i can even drop the hole user directory if i want...

[annevk]

Did you mean to file this against https://wicg.github.io/file-system-access/? That's not an API this standard describes.

[jimmywarting]

hmm, yea maybe, i thought it was renamed/moved to this repo instead?

[annevk]

Only partially, see WICG/file-system-access#342 for details.

[jimmywarting]

Hmm, so if i understand it right, essentially what is splitet out is

• the file system (this) of how it should operate with move/rename/create files & folder etc, so it can focus mainly on a eg a sandboxed browser storage from navigator.storage.getDirectory(), so that firefox and safari can implement it without worrying about any security issues about exposing sensitive access?
• And the other repo is mainly just about prompting and getting access to pick and save files to a user specific directory?

[annevk]

Yup.

[jimmywarting]

Ty, that makes it very clear!

Should be mention somewhere in both readme/explainers that file-system-access is not ment to be confused with whatwg/fs.
that: "file-system-access" is just a method of getting permission to use a own path of user own choosing and giving back a whatwg/fs handle back. new feature request like "watching for file changes and recursively create a directory, etc" should be done to whatwg/fs and permission/security scans related things should be done to file-system-access. 🙂

[annevk]

I suspect that will happen as part of the issue I linked above.