bftw: Recover from ENAMETOOLONG

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).

0 files changed, 0 insertions, 0 deletions