Que signifient les «fonctionnalités activées» dans GNU?

Lorsque j'utilise find --versionavec GNU find, j'obtiens quelque chose comme ceci:

find (GNU findutils) 4.5.9     
[license text]
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION FTS(FTS_CWDFD) CBO(level=2)

Que signifient ces «fonctionnalités»? Il y a une référence à O_NOFOLLOWêtre une mesure de sécurité man find, et il y a une mention d' LEAF_OPTIMISATIONêtre une optimisation qui enregistre quelques lstatappels sur les nœuds feuilles. Mais je ne peux pas trouver quoi que ce soit au sujet FTS, D_TYPEou CBO.

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.

Des informations sur O_NOFOLLOWsont données dans la infopage de find:

9.2.1.1 O_NOFOLLOW

..................

Si votre système prend en charge l'indicateur O_NOFOLLOW (1), la open(2)' system call,recherche l'utilise lors du changement de répertoire en toute sécurité. Le répertoire cible est d'abord ouvert, puis l' find' changes working directory with theappel système fchdir () '. Cela garantit que les liens symboliques ne sont pas suivis, empêchant le type d'attaque de condition de concurrence dans laquelle les liens symboliques sont utilisés.

...

Dans l'arborescence source, CBOapparaît uniquement dans le fichier parser.c:

 printf("CBO(level=%d) ", (int)(options.optimisation_level)); 

indiquant qu'il s'agit d'une optimisation basée sur les coûts (ma meilleure estimation).

D_TYPE se produit à plusieurs endroits dans l'arborescence source et semble avoir à voir avec le type d'entrée de répertoire:

$ grep 'D_TYPE' */**

Rendements:

find/parser.c:#if defined USE_STRUCT_DIRENT_D_TYPE && defined HAVE_STRUCT_DIRENT_D_TYPE
lib/savedirinfo.c:#if defined HAVE_STRUCT_DIRENT_D_TYPE && defined USE_STRUCT_DIRENT_D_TYPE

et quelques entrées supplémentaires. Vous pouvez trouver la source ici .

En parcourant l'arbre source de findutils ( http://git.savannah.gnu.org/cgit/findutils.git/tree/ ), j'ai trouvé ce qui suit:

• configure.ac: --enable-d_type-optimisation, utilisez les données de type de fichier renvoyées dans struct dirent.d_type par readdir ()),
• m4 / withfts.m4: --without-fts Utilisez un mécanisme plus ancien pour rechercher le système de fichiers, au lieu d'utiliser fts ()

Je n'ai rien trouvé sur CBO; vous devrez peut-être télécharger le code source et rechercher le terme ..