walkdir

Currently only considers directories below the starting directory. The recursive walk happily follows links to directories above that, including to . I discovered this when vscode used ripgrep to search for in a project directory that contained a WINEPREFIX, including the typical -> symlink. It followed its multi-threaded code path and didn't use walkdir, so the outcome was much worse, but if it had used walkdir it still would have emitted 2k+ invalid matches all over my filesystem and 300k+ lines to stderr about /proc and /dev access failures before I eventually killed it for maxing out a cpu core. This PR takes seeds with the ancestor directories so they are included in the loop check. now takes a rather than a . On Windows it opens a handle per ancestor and holds it for the walk, as it already does for the rest of , so a deep root costs a few more descriptors. There are three new tests included. See https://github.com/BurntSushi/ripgrep/pull/3534 The code and commit message for this PR were authored approximately 60% by Claude Opus 5.

Description Resolves #167. This PR addresses two documentation inaccuracies / omissions regarding : 1. Updates comments on and that described closed directory handles as reading into a . The internal representation yields , not . 2. Adds a clarifying note under in noting that unlike on some platforms which retains an open directory handle/file descriptor, does not retain an open descriptor. Verification : 47 unit tests passed, 20 doc-tests passed. : documentation rendered cleanly without warnings.

To quote https://github.com/BurntSushi/walkdir/issues/23#issuecomment-4323489497 tl;dr; of the above relevant discussions: The correct way to do this on UNIX-like OSes is to use openat to open relative to the parent directory. That's exactly right. Fix #23, #181, #209 and others https://github.com/BurntSushi/walkdir/issues/120 is also related --- the safe approach is more performant too, and that issue ended up discussing reimplementing things along these lines. I and my coworkers would be happy to take a stab at contributing this. We can use for now, and https://github.com/rust-lang/rust/issues/120426 later once it is stable.