GoogleChromeLabs / browser-fs-access

File System Access API with legacy fallback in the browser
https://googlechromelabs.github.io/browser-fs-access/demo/
Apache License 2.0
1.37k stars 82 forks source link

directoryOpen does not allow creating new files in an empty directory #129

Closed reubenfirmin closed 1 year ago

reubenfirmin commented 1 year ago

directoryOpen() returns a 0 length array of FileWithDirectoryAndFileHandle if there is nothing inside the directory having been opened. In my case I'm opening with a mode of readwrite, so Chrome nicely prompts me that the application will have access to the directory. Per https://wicg.github.io/file-system-access/#api-filesystemdirectoryhandle, I can create new files by calling getFileHandle(create=true) on a directory handle; however, because directoryOpen returns 0 length, I don't have a directory handle to create the initial file in.

If there's an alternate way to accomplish this, please advise; but, I think the fix is to include a FileSystemDirectoryHandle as part of the directoryOpen response.

(I'm making an app with no server; data is stored in localstorage, and I'm adding sync to and from the filesystem.)

reubenfirmin commented 1 year ago

In fact, yes - including this dirHandle would do it:

https://github.com/GoogleChromeLabs/browser-fs-access/blob/main/src/fs-access/directory-open.mjs#L26

tomayac commented 1 year ago

Since the result needs to be backward-compatible with <input type=file webkitdirectory>, which is a FileList that ignores empty directories (and in the case of File System Access API support is an array of files), I think one way to make this happen would be add a boolean flag like includeEmptyDirectories that would return something like a Linux . "fake file" (not even sure what this is technically, a link to the current directory?) per directory. Another way would be to likewise have a flag, but then return an object that represents the file hierarchy, but that then is no longer compatible with FileList. Any other way that I'm not thinking of right now?

reubenfirmin commented 1 year ago

The flag that leads to a "." equivalent being returned as part of the results would work fine by me.

tomayac commented 1 year ago

@beaufortfrancois suggests maybe having a completely new convenience function fileHierarchy() or so might be cleanest, which would only work if the File System Access API is supported. The point of browser-fs-access is to be a ponyfill (not polyfill), so this potential new function that only works when the File System Access API is supported would be kind of against its philosophy, but I can see how it would add value. Do you want to work on a PR that would add it as a new file file-hierarchy.mjs in src/fs-access/?

reubenfirmin commented 1 year ago

Sure. I'm not much of a js programmer, but I followed the pattern in the codebase.

https://github.com/GoogleChromeLabs/browser-fs-access/pull/132

I chose to delegate to directoryOpen rather than reimplementing most of it - let me know what you think. I will test more thoroughly if the code looks reasonable.

tomayac commented 1 year ago

This was fixed in v0.32.1.