v6.4.1
Fixes
Recursive symlinks handling (#125)
Previously, fdir left it up to the OS to handle recursive symlinks. Unfortunately, this resulted in an infinite loop that'd either cause a crash or take too long to resolve (each OS has a different limit on resolving recursive symlinks). This has been fixed now in #126.
Recursive symlinks with resolvePaths: true
When resolvePaths
is set to true
, fdir
does not crawl a directory it has already visited. To figure out whether we have visited a directory or not, fdir
maintains a list of all the directories it has visited. This might result in slightly higher memory usage than before.
For a directory that looks like this:
/dir/
file
symlink -> /dir/
fdir will return:
[ "/dir/file" ]
In short, you won't see duplicated paths in the output which is the expected behavior when working with file systems since paths are unique.
Recursive symlinks with resolvePaths: false
When you set resolvePaths
to false
, the behavior differs because now all symlinks become part of the path.
For a directory that looks like this:
/dir/
file
symlink -> /dir/
fdir will return:
[ "/dir/file", "/dir/symlink/file" ]
To prevent recursion, all recursive symlinks are only resolved a single level deep making sure you never see something like /dir/symlink/symlink/symlink/file
. This allows for glob patterns to work with recursive symlinks without creating a performance issue.
Relative recursive symlinks
Relative recursive symlinks work exactly as above except the returned paths are relative to the root. Everything else is exactly the same.
Thanks to @SuperchupuDev for bringing this to my attention.