Closed steveskimmel closed 1 year ago
Could it be due to different ways of dealing with hidden files? Windows saves different metadata files like image thumbnails etc. On macOS, the same happens with .DS_Store
files. If, for example, you check the same USB pen first on Windows and then on macOS, the second OS will add metadata that was not yet there when you tested on the first.
I don't think that's the case. On prior Chromium versions (109 for example), file detection from within nested directories worked perfectly.
In this case, it sounds more like a Chrome bug. Could you please try to create a minimally reproducible test case and file a new Chromium bug via new.crbug.com. You can comment with the bug URL here, and I can help triaging. For now, I'm closing the issue, since it's not with the library apparently.
Could you append screenshots that show how the same code delivers different results based on the operating system and the Chrome version? These should be the screenshots I expect:
At present the issue doesn't mention the problem you describe in https://github.com/GoogleChromeLabs/browser-fs-access/issues/139#issuecomment-1456056717.
(Sorry, I meant as attachments to the bug. Please use descriptive file names. Thanks a lot!
Cool, I've done that. Thanks.
The new File System Access API is not performing properly when processing large directories (500+ files) using the latest Chromium browsers on MacOs (110+). The same code performs properly on Chromium browsers (110+) on Windows.
The following example yields different results:
On MacOs, the result consistently yields less than all the files in nested directories. On Windows, the result yields all of the files in nested directories.
I'm trying to understand why this is the case, and what the solution is to properly access all the files in nested directories on all operating systems?
Thank you