directoryOpen does not allow creating new files in an empty directory

[reubenfirmin]

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]

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]

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]

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

[tomayac]

@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]

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

#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]

This was fixed in v0.32.1.