rm (and others) can't handle paths longer than PATH_MAX

[Tavian Barnes]

For example:

$ name="0123456789ABCDEF"
$ name="${name}${name}${name}${name}"
$ name="${name}${name}${name}${name}"
$ name="${name:0:255}"
$ (mkdir deep && cd deep && for i in {1..17}; do mkdir $name && cd $name; done)
$ busybox rm -rf deep
rm: can't stat 'deep/...': Filename too long
rm: can't remove 'deep/...': Directory not empty
...
$ busybox rm -v
BusyBox v1.28.1 (2018-02-19 12:49:35 MSK) multi-call binary.

busybox find deep is similarly broken.  But POSIX says in
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html:

> The rm utility is required to descend to arbitrary depths so that any file hierarchy may be deleted. This means, for example, that the rm utility cannot run out of file descriptors during its descent (that is, if the number of file descriptors is limited, rm cannot be implemented in the historical fashion where one file descriptor is used per directory level). Also, rm is not permitted to fail because of path length restrictions, unless an operand specified by the user is longer than {PATH_MAX}.

And in http://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html:

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

-- 
Tavian Barnes