GNU findの「アクティブ化された機能」とはどういう意味ですか？

これはKetanとDaniel Kullmanの答えと私の研究の完全な答えです。

ほとんどの「機能」はクエリの最適化です。findこれは通常、ファイルシステムで（ほぼ）任意に複雑なクエリを実行できるためです。

D_タイプ

この機能が存在するということは、このフィールドがLinuxでも採用されたBSD拡張であるD_TYPEことを意味しfind、andfriendsから返された構造にファイルタイプ（ディレクトリ、ファイル、パイプ、ソケット、文字/ブロックデバイスなど）を提供します。 ）。最適化としてこれを使用すると、フィルタ式として使用されるときに呼び出しを減らしたり削除したりできます。d_typestruct direntreaddirfindlstat-type

readdird_type一部のファイルシステムでは常に埋められない可能性があるため、lstat依然として必要な場合があります。

公式文書の追加情報：https://www.gnu.org/software/findutils/manual/html_node/find_html/d_005ftype-Optimization.html

O_NOFOLLOW

オプションは(enabled)またはで表示されます(disabled)。存在して有効になっている場合、この機能は特定のfindTOCTTOUレース攻撃を防ぐセキュリティ対策を実装します。特に、findファイルの種類を確認した後、ディレクトリに入る前にディレクトリがシンボリックリンクに置き換えられた場合に発生する可能性があるディレクトリナビゲーションを実行するときにシンボリックリンクが通過するのを防ぎます。

このオプションを有効にすると、物理ディレクトリのみを開くことがディレクトリで使用され、そのディレクトリのファイルを開くために使用されますfind。open(..., O_NOFOLLOW)openat

LEAF_OPTIMISATION

この少しあいまいな最適化をfind使用すると、親ディレクトリのリンク数を使用して、親ディレクトリのどのサブディレクトリがディレクトリかを推測できます。これは、サブディレクトリが（linksを介して..）親ディレクトリのリンク数に影響を与えるためです。場合によっては、呼び出しをfind省略できますstat。ただし、ファイルシステムまたはオペレーティングシステムがそれを間違って表示すると、間違った結果が発生する可能性がst_nlinksありますfind（幸いなことにそうではありません）。

詳しくは公式ドキュメントをご覧ください。https://www.gnu.org/software/findutils/manual/html_node/find_html/Leaf-Optimization.html

FTS

有効にすると、このFTS機能をfind使用します。fts再帰を直接実装するのではなく、ファイル階層をナビゲートするためのAPIです。

利点が何であるかはわかりませんが、基本的にftsこれまでに見たFTSすべての基本バージョンのデフォルトです。find

追加情報：https://www.gnu.org/software/findutils/manual/html_node/find_html/fts.html、http://man7.org/linux/man-pages/man3/fts.3.html

議会予算処

find（ダニエルクールだけが提案したソースコードを読んだ後）、「CBO」はクエリ最適化レベル（「コストベースのオプティマイザ」を表す）を意味することがわかりました。たとえば、これを行うと、次のようなfind -O9001 --version結果が得られます。

Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION FTS() CBO(level=9001) 

-Oのオプションを見てくださいman find。

-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.

謎が解けました！オプションがランタイム値であることは少し奇妙です。通常、出力に--versionはコンパイル時オプションのみが反映されると予想されます。