sharkdp/fd

[BUG] `fd` cannot handle arbitrary deep directories like GNU `find`

Open

#1985 opened on Apr 26, 2026

View on GitHub
 (1 comment) (0 reactions) (0 assignees)Rust (42,984 stars) (1,059 forks)batch import
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

Contributor guide