| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
bftw_stream() was always pushing to the end of the queue, resulting in
breadth-first behaviour even when BFTW_DFS was set. This made iterative
deepening a "worst of both worlds" with the same memory use as BFS, but
much slower due to re-traversals.
Fix it by re-using bftw_batch_{start,finish} from bftw_batch().
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
POSIX now says -mount should skip the whole mount point, while -xdev
should only skip its descendents.
C.f. http://austingroupbugs.net/view.php?id=1133
C.f. https://savannah.gnu.org/bugs/?42318
C.f. https://savannah.gnu.org/bugs/?54745
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This is a re-introduction of 998ba6f, which was reverted by the
introduction of bftw_reader in 68ae5d0. It's particularly relevant for
depth-first searches now that we queue each file before visiting it.
|
|
|
|
| |
This makes the order be truly depth-first.
|
| |
|
|
|
|
|
| |
It's not used by bfs, and it's difficult to support in all search
strategies.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This makes `bfs a b` treat `a` and `b` as siblings.
|
| |
|
|
|
|
| |
I don't think this can cause any observable bugs, but it's still wrong.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
C.f. https://savannah.gnu.org/bugs/?54913
C.f. https://lkml.org/lkml/2019/2/11/2027
Fixes https://github.com/tavianator/bfs/issues/37
|
| |
|
|
|
|
| |
Turns out incomplete enum types are a GNU C extension.
|
| |
|
| |
|
| |
|
|
|
|
| |
The performance is within 1% with much simpler code.
|
|
|
|
|
|
| |
GCC doesn't (yet) produce very fast code for strcmp() against constant
strings (see https://gcc.gnu.org/PR78809), so hand-coding the comparison
manually helps significantly.
|
|
|
|
|
|
|
|
|
|
| |
There were two problems:
- bubble_down() would always bubble the entry all the way down the heap,
instead of stopping at the appropriate place
- remove() may need to bubble the replacement entry *up* the heap, if it
came from a different subtree
|
|
|
|
|
| |
This lets bfs transparently support the new statx() system call on
Linux, giving it access to file birth times.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Rather than open-code the fallback logic for broken symlinks everywhere
it's needed, introduce a new xfstatat() utility function that performs
the fallback automatically.
Using xfstatat() consistently fixes a few bugs, including cases where
broken symlinks are given as arguments to predicates like -samefile.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
For a/b/c, ENOTDIR is returned instead of ENOENT if a or b are not
directories. Handle this uniformly when detecting broken symlinks,
readdir races, etc.
|
| |
|
|
|
|
|
| |
The root has depth == 0, but we still need to include it in the
components array.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is always possible to force a breadth-first traversal to encounter
ENAMETOOLONG, regardless of the dircache eviction policy. As a concrete
example, consider this directory structure:
./1/{NAME_MAX}/{NAME_MAX}/{NAME_MAX}/... (longer than {PATH_MAX})
./2/{NAME_MAX}/{NAME_MAX}/{NAME_MAX}/...
./3/{NAME_MAX}/{NAME_MAX}/{NAME_MAX}/...
...
(more than RLIMIT_NOFILE directories under .)
Eventually, the next file to be processed will not have any parents in
the cache, as the cache can only hold RLIMIT_NOFILE entries. Then the
whole path must be traversed from ., which will exceed {PATH_MAX} bytes.
Work around this by performing a component-by-component traversal
manually when we see ENAMETOOLONG. This is required by POSIX:
> The find utility shall be able to descend to arbitrary depths in a file
> hierarchy and shall not fail due to path length limitations (unless a
> path operand specified by the application exceeds {PATH_MAX}
> requirements).
|
|
|
|
|
|
|
| |
This reverts commit 20860becb5a0e89ee2aaaddbb0ba1eb248552640.
The terminating NUL will be useful for the upcoming per-component
traversal to handle ENAMETOOLONG.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Quadratic complexity is still possible for directory structures like
root -- a -- a -- a -- a ...
|
+- b -- b -- b -- b ...
But for most realistic directory structures, bfs should now spend less
time building paths.
(Of course if you print every path, overall complexity is quadratic
anyway.)
|