Skip to content

v6.4.1

Compare
Choose a tag to compare
@thecodrr thecodrr released this 16 Oct 18:33
· 3 commits to master since this release

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.