Ceci est une réponse complète dérivée des réponses de Ketan et de Daniel Kullman, ainsi que de mes propres recherches.
La plupart des "fonctionnalités" s'avèrent être des optimisations de requêtes, car elles findsont en général capables de requêtes (presque) arbitrairement complexes sur le système de fichiers.
D_TYPE
La présence de la D_TYPEfonctionnalité signifie qu'elle a findété compilée avec le support du d_typechamp en struct dirent. Ce champ est une extension BSD également adoptée par Linux, qui fournit le type de fichier (répertoire, fichier, pipe, socket, périphérique char / block, etc.) dans la structure renvoyée par readdiret amis. En optimisation,find pouvez l'utiliser pour réduire ou éliminer les lstatappels lorsqu'il -typeest utilisé comme expression de filtre.
readdir ne remplit pas toujours d_type sur certains systèmes de fichiers, donc parfois un lstatsera toujours nécessaire.
Plus d'informations dans la documentation officielle: https://www.gnu.org/software/findutils/manual/html_node/find_html/d_005ftype-Optimisation.html
O_NOFOLLOW
Cette option affichera soit (enabled)ou (disabled). Si elle est présente et activée, cette fonction met en œuvre une mesure de sécurité qui protègefind de certaines attaques de course TOCTTOU. Plus précisément, il empêche findde traverser un lien symbolique lors de la traversée du répertoire, ce qui pourrait se produire si le répertoire était remplacé par un lien symbolique après la vérification du type de fichier du répertoire mais avant la saisie du répertoire.
Avec cette option activée, findutilisera open(..., O_NOFOLLOW)sur le répertoire pour ouvrir uniquement les vrais répertoires, puis utilisera openatpour ouvrir les fichiers dans ce répertoire.
LEAF_OPTIMISATION
Cette optimisation légèrement obscure permet findde déduire quels sous-répertoires d'un répertoire parent sont des répertoires en utilisant le nombre de liens du répertoire parent, car les sous-répertoires contribueront au nombre de liens du parent (via le ..lien). Dans certaines circonstances, cela permettra findd'éluder un statappel. Cependant, si le système de fichiers ou le système d'exploitation déforme st_nlinks, cela peut entraîner finddes résultats faux (c'est heureusement un événement très rare).
Plus d'informations dans la documentation officielle: https://www.gnu.org/software/findutils/manual/html_node/find_html/Leaf-Optimisation.html
FTS
Lorsqu'elle est activée, la FTSfonction oblige findà utiliser l' ftsAPI pour parcourir la hiérarchie des fichiers, au lieu d'une implémentation récursive directe.
Je ne sais pas clairement quel est l'avantage fts, mais FTSc'est essentiellement la valeur par défaut sur toutes les findversions par défaut que j'ai vues jusqu'à présent.
Plus d'informations: https://www.gnu.org/software/findutils/manual/html_node/find_html/fts.html , http://man7.org/linux/man-pages/man3/fts.3.html
CBO
Il s'avère (après avoir lu le findcode source comme suggéré par Daniel Kullman) que "CBO" se réfère au niveau d'optimisation de requête (il signifie "optimiseur basé sur les coûts"). Par exemple, si je le fais find -O9001 --version, je reçois
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION FTS() CBO(level=9001)
En regardant l' -Ooption dans man find, je vois
-Olevel
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.
Mystère résolu! Il est un peu étrange que l'option soit une valeur d'exécution; habituellement, je m'attendrais à ce que la --versionsortie reflète uniquement les options de compilation.