-
Notifications
You must be signed in to change notification settings - Fork 23
Convenience method for recursive directory iteration #15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
question: How would we deal with knowing the path of some handle when going into recursive mode? |
You could use resolve() (or whatever we rename it to, the name is ugly) |
ah, forgot about the resolve, yea the name is a bit weird, it don't stick and immediately tells you what the fn dose for something... think it's in conflict with the how about:
|
I had proposed some alternatives names in #4 (comment). Let's move the naming discussions to that issue |
If this is implemented as parameters to the asynchronous iterator initialization for a directory handle (i.e. parameters to values, keys and entries) presumably the keys returned by keys and entries could somehow return the entire path as well, avoiding the need for a separate path lookup... |
So do we need a recursive iterator? IIRC most OS's don't provide such a thing; it's easy enough to build on top of the existing interfaces. |
I do think most terminal have a recursive mode when searching/deleting files |
Cli commands have different requirements and reasoning for options than API calls. |
Migrated from WICG/file-system-access#173 (see #2)
It should be easy to read only files or subfolders from a parent folder, and have a recursive option to return the contents of subfolders. Example:
The text was updated successfully, but these errors were encountered: