[Bug]: infinite paths on Add a new story: ENAMETOOLONG. Function unavailable
haraldrudell opened this issue · comments
Describe the bug
When attempting to document a new component, component search fails
BUG:
A large RED popup window with white text beginning
An error occurred while searching for components in the project. ENAMETOOLONG: name too long, scandir '/
IMPACT:
No components can be documented using the UI
may occur for any user on any host
SYMPTOMTS:
—1 the paths listed are away from the project directory but in the root file-system directory in which the project is located
—2 Storyboard is for some reason scanning directories outside the project directory
—3 The BUG can occur for any user on any host
Apparently, scanning is not filtered for cyclic symbolic paths. A map of absolute paths is going to be required
file systems do not guarantee the path to a particular node being unique even when symlinks are resolved, so a limit on recursion must be implemented, like Go limits to 100 symlinks
CAUSE:
some permitted use of symlinks in the file system that Storybook decides to scan but is unable to successfully complete
Reproduction link
N/A
Reproduction steps
install vanilla storybook
on browser Storybook page, click +next to Find Components search box
In lightbox Add a new story ./components/**/*.tsx search box, type a character
System
macOS 14.5 vite React Storybook 8.1+
Additional context
No response
Appears to be caused by, in this case, a Go project having a fakeGoPATH directory structure eventually symlinked back to its own go.mod in a relative parent directory
ls -l …
xyz -> ../../../..
I think this was something before Go modules became widely used
—
What one could do here is to model that scandir code on Go’s filepath.EvalSymlinks https://pkg.go.dev/path/filepath#EvalSymlinks
@google wrote that, it works
this code here walks anything avoiding recursion from cyclic paths. It doesn’t include the latest learnings but won’t crash
I don’t know for anybody else doing this. Like @facebook doesn’t
https://pkg.go.dev/github.com/haraldrudell/parl@v0.4.184/pfs#Traverser
walking symlinks is a huge problem space
This code could be easily transpiled to ECMAScript and it will work every time
@valentinpalkovic I am able to reproduce this in a sandbox:
- Remove
/sandbox
from.gitignore
- Run the sandbox and search for
button
=> it will return a bunch of results - Link a parent directory
ln -s ../../.. boom
- Run the sandbox and search for
button
=> it will hang -- I think it is traversing the symlink infinitely
I tried adding the following options to globby
but it did not fix the problem:
followSymbolicLinks: false,
onlyFiles: true,
When I remove gitignore: true
from the options:
- It does fix the problem (
followSymLinks
is respected) - The glob runs twice as fast (500ms vs 1000+ms with gitignore)
Therefore it seems globby
gitignore is buggy and also introduces a performance regression. I wonder if we can get a fix into globby
?
In my opinion, setting followSymbolicLinks: false
wouldn't be an option. Symlinks are common, and when properly set up, they usually don't cause loops.
Since globby
respects the user's gitignore, wouldn't a further entry in the gitignore file solve the issue by excluding the symlinked folder?
@shilman Also, could you experiment with the deep option? By default, it is set to Infinity.
Maybe we should limit the folder depth to, for example, 100.
@haraldrudell Just for context: We haven't implemented the glob search by ourselves, but we rely on the globby library. If you think cyclical symlinks should be treated in a different way, then I think it makes sense to open a bug report there, unless it is not configurable by globby itself.
@valentinpalkovic I don't think deep
is a good solution. deep: 50
still blows up, and deep: 20
works but takes 10 seconds to complete a single search.
This bug is important to me because I want to use fileSearch
as part of some telemetry and I need it to be performant. It would run on startup once per day (I'd cache the results). I suppose I could pass followSymbolicLinks: false
JUST for the telemetry case and we could leave it to true
for the search UI. But it's a bummer that gitignore doesn't play nice with followSymLinks
.