sharkdp/fd
View on GitHub[BUG] `fd` cannot handle arbitrary deep directories like GNU `find`
Open
#1985 opened on Apr 26, 2026
bughelp wantedupstream-error
Description
Checks
- I have read the troubleshooting section and still think this is a bug.
Describe the bug you encountered:
One of the nice features of GNU find and many other GNU programs is that they avoid arbitrary limits whenever possible. As a result, GNU mkdir can create arbitrarily deep directories which find can then visit:
$ mkdir -p $(yes a/ | head -n 32768 | tr -d '\n')
$ find a | wc -l
32768
This is not the case with fd:
$ ./target/release/fd a | wc -l
2062
Using strace, we can see that fd constructs the file names in full each time and calls statx(2) instead of operating on file descriptors. This means fd reaches PATH_MAX limitations:
$ strace -ff -e trace=statx ./target/release/fd -j 1 '' a 2>&1 | grep '= -1'
[...]
[pid 344540] statx(AT_FDCWD, "[long file name trimmed]"..., AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7fdb3c3fbcf0) = -1 ENAMETOOLONG (File name too long)
[...]
It also gives a misleading non-zero exit status after failing to list all of the file names:
$ ./target/release/fd -j 1 '' a > /dev/null
$ echo $?
0
Describe what you expected to happen:
No response
What version of fd are you using?
fd 10.4.2
Which operating system / distribution are you on?
$ uname -srm
Linux 6.18.4-200.fc43.x86_64 x86_64
$ lsb_release -a
LSB Version: n/a
Distributor ID: Fedora
Description: Fedora Linux 43 (Workstation Edition)
Release: 43
Codename: n/a