summaryrefslogtreecommitdiffstats
path: root/tests/test_deep.out
Commit message (Collapse)AuthorAgeFilesLines
* tests: Make test_deep pass with other find implementationsTavian Barnes2017-09-041-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 closedTavian Barnes2017-07-081-8/+8
| | | | | The root has depth == 0, but we still need to include it in the components array.
* bftw: Recover from ENAMETOOLONGTavian Barnes2017-07-081-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).