summaryrefslogtreecommitdiffstats
path: root/tests/test_depth_maxdepth_2.out
diff options
context:
space:
mode:
authorTavian Barnes <tavianator@tavianator.com>2017-07-08 14:11:50 -0400
committerTavian Barnes <tavianator@tavianator.com>2017-07-08 14:47:42 -0400
commit2a3eab05901f32aeabf0e4b45d5b50fdf056e23d (patch)
treea3a4839f72ee203244ef7f892b5328a01f20e14c /tests/test_depth_maxdepth_2.out
parentd24ecd23c4aec43788b61d30dbf78a894626c3c9 (diff)
downloadbfs-2a3eab05901f32aeabf0e4b45d5b50fdf056e23d.tar.xz
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).
Diffstat (limited to 'tests/test_depth_maxdepth_2.out')
0 files changed, 0 insertions, 0 deletions