This is a complete answer derived from the answers of Ketan and daniel kullman, as well as my own research.
Most of the "features" turn out to be query optimizations, since
find is in general capable of (almost) arbitrarily complex queries on the filesystem.
The presence of the
D_TYPE feature means that
find was compiled with support for the
d_type field in
struct dirent. This field is a BSD extension also adopted by Linux, which provides the file type (directory, file, pipe, socket, char/block device, etc.) in the structure returned from
readdir and friends. As an optimization,
find can use this to reduce or eliminate
lstat calls when
-type is used as a filter expression.
readdir may not always populate
d_type on some filesystems, so sometimes an
lstat will still be needed.
More info from the official documentation: https://www.gnu.org/software/findutils/manual/html_node/find_html/d_005ftype-Optimisation.html
This option will read either
(disabled). If present and enabled, this feature implements a security measure that protects
find from certain TOCTTOU race attacks. Specifically, it prevents
find from traversing a symlink while performing directory traversal, which could occur if the directory were replaced by a symlink after the directory's filetype was checked but before the directory was entered.
With this option enabled,
find will use
open(..., O_NOFOLLOW) on the directory to open only real directories, then use
openat to open files within that directory.
This slightly obscure optimization allows
find to deduce which subdirectories of a parent directory are directories by using the link count of the parent directory, since subdirectories will contribute to the link count of the parent (via the
.. link). In certain circumstances, it will allow
find to elide a
stat call. However, if the filesystem or OS misrepresents
st_nlinks, it may cause
find to produce bogus results (this is thankfully a very rare occurrence).
More info in the official documentation: https://www.gnu.org/software/findutils/manual/html_node/find_html/Leaf-Optimisation.html
When enabled, the
FTS feature causes
find to use the
fts API to traverse the file hierarchy, instead of a straight recursive implementation.
It's not clear to me what the advantage of
fts is, but
FTS is basically the default on all default
find versions I've seen so far.
More info: https://www.gnu.org/software/findutils/manual/html_node/find_html/fts.html, http://man7.org/linux/man-pages/man3/fts.3.html
It turns out (after reading the
find source code as suggested by daniel kullman) that "CBO" refers to the query optimization level (it stands for "cost-based optimizer"). For example, if I do
find -O9001 --version, I get
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION FTS() CBO(level=9001)
Looking at the
-O option in
man find, I see
Enables query optimisation. The find program reorders tests to speed up execution while preserving the overall
effect; that is, predicates with side effects are not reordered relative to each other. The optimisations performed
at each optimisation level are as follows.
0 Equivalent to optimisation level 1.
1 This is the default optimisation level and corresponds to the traditional behaviour. Expressions are
reordered so that tests based only on the names of files (for example -name and -regex) are performed first.
2 Any -type or -xtype tests are performed after any tests based only on the names of files, but before any
tests that require information from the inode. On many modern versions of Unix, file types are returned by
readdir() and so these predicates are faster to evaluate than predicates which need to stat the file first.
3 At this optimisation level, the full cost-based query optimiser is enabled. The order of tests is modified
so that cheap (i.e. fast) tests are performed first and more expensive ones are performed later, if neces-
sary. Within each cost band, predicates are evaluated earlier or later according to whether they are likely
to succeed or not. For -o, predicates which are likely to succeed are evaluated earlier, and for -a, predi-
cates which are likely to fail are evaluated earlier.
The cost-based optimiser has a fixed idea of how likely any given test is to succeed. In some cases the probability
takes account of the specific nature of the test (for example, -type f is assumed to be more likely to succeed than
-type c). The cost-based optimiser is currently being evaluated. If it does not actually improve the performance
of find, it will be removed again. Conversely, optimisations that prove to be reliable, robust and effective may be
enabled at lower optimisation levels over time. However, the default behaviour (i.e. optimisation level 1) will not
be changed in the 4.3.x release series. The findutils test suite runs all the tests on find at each optimisation
level and ensures that the result is the same.
Mystery solved! It's a little strange that the option is a runtime value; usually I would expect the
--version output only to reflect compile-time options.