bfs.git - Breadth-first version of find

	Commit message (Collapse)	Author	Age	Files	Lines
*	tests: Split test cases into separate files	Tavian Barnes	2022-10-19	1	-16/+0
\|
*	tests: Make test_deep pass with other find implementations	Tavian Barnes	2017-09-04	1	-8/+16
\| \| \| \| \|	And move test_deep_strict to the bfs-specific tests, since it's not likely to ever pass for other implementations.
*	bftw: Fix ENAMETOOLONG handling when the root is closed	Tavian Barnes	2017-07-08	1	-8/+8
\| \| \| \| \|	The root has depth == 0, but we still need to include it in the components array.
*	bftw: Recover from ENAMETOOLONG	Tavian Barnes	2017-07-08	1	-0/+8
	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).