Questa è una risposta completa derivata dalle risposte di Ketan e Daniel Kullman, nonché dalla mia ricerca.
La maggior parte delle "caratteristiche" risultano essere ottimizzazioni delle query, poiché findin generale è in grado di eseguire query (quasi) arbitrariamente complesse sul filesystem.
D_TYPE
La presenza della D_TYPEfunzione indica che è findstato compilato con il supporto per il d_typecampo in struct dirent. Questo campo è un'estensione BSD adottata anche da Linux, che fornisce il tipo di file (directory, file, pipe, socket, dispositivo char / block, ecc.) Nella struttura restituita da readdire amici. Come ottimizzazione, findpuoi utilizzarlo per ridurre o eliminare le lstatchiamate quando -typeviene utilizzato come espressione di filtro.
readdirpotrebbe non essere sempre popolato d_typesu alcuni filesystem, quindi a volte è lstatancora necessario un testamento.
Maggiori informazioni dalla documentazione ufficiale: https://www.gnu.org/software/findutils/manual/html_node/find_html/d_005ftype-Optimisation.html
O_NOFOLLOW
Questa opzione leggerà (enabled)o (disabled). Se presente e abilitata, questa funzione implementa una misura di sicurezza che protegge findda determinati attacchi di razza TOCTTOU. In particolare, impedisce finddi attraversare un collegamento simbolico mentre si esegue l'attraversamento della directory, il che potrebbe verificarsi se la directory fosse sostituita da un collegamento simbolico dopo il controllo del tipo di file della directory ma prima dell'accesso alla directory.
Con questa opzione abilitata, findverrà utilizzata open(..., O_NOFOLLOW)nella directory per aprire solo directory reali, quindi utilizzare openatper aprire i file all'interno di tale directory.
LEAF_OPTIMISATION
Questa ottimizzazione leggermente oscura consente finddi dedurre quali sottodirectory di una directory padre sono directory utilizzando il conteggio dei collegamenti della directory padre, poiché le sottodirectory contribuiranno al conteggio dei collegamenti del padre (tramite il ..collegamento). In determinate circostanze, consentirà finddi eludere una statchiamata. Tuttavia, se il filesystem o il sistema operativo travisano st_nlinks, potrebbe causare findrisultati falsi (questo per fortuna è un evento molto raro).
Maggiori informazioni nella documentazione ufficiale: https://www.gnu.org/software/findutils/manual/html_node/find_html/Leaf-Optimisation.html
FTS
Quando abilitata, la FTSfunzione fa sì findche l' ftsAPI attraversi la gerarchia dei file, anziché un'implementazione ricorsiva diretta.
Non mi è chiaro quale sia il vantaggio fts, ma FTSè fondamentalmente il valore predefinito su tutte le findversioni predefinite che ho visto finora.
Ulteriori informazioni: https://www.gnu.org/software/findutils/manual/html_node/find_html/fts.html , http://man7.org/linux/man-pages/man3/fts.3.html
CBO
Si scopre (dopo aver letto il findcodice sorgente come suggerito da Daniel Kullman) che "CBO" si riferisce al livello di ottimizzazione della query (sta per "ottimizzatore basato sui costi"). Ad esempio, se lo faccio find -O9001 --version, ottengo
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION FTS() CBO(level=9001)
Guardando l' -Oopzione in man find, vedo
-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.
Mistero risolto! È un po 'strano che l'opzione sia un valore di runtime; di solito mi aspetto che l' --versionoutput rifletta solo le opzioni di compilazione.