Estou tentando mostrar /usr/bin/findalgo significativo sem fazer nenhum tipo de coisa stat, sem resultados úteis até agora. Se eu inibir à força stat, encontre paradas de descida para subdiretórios.
Como getdentsdiz a página de manual do syscall, existe d_typeum campo lá, então findjá deve ter algumas informações necessárias para decisões.
Por que é necessário , statindependentemente de ou quaisquer opções.-L-H
Responder1
Use a fonte, Lucas!
Na findfonte GNU (estou olhando para a versão 4.2.2), o código que percorre as árvores de diretórios está em gnulib/lib/fts.c. Na linha 1123 há o seguinte comentário:
Registre o que fts_read terá a ver com esta entrada. Em muitos casos, ele simplesmente fará fts_stat, mas podemos aproveitar qualquer informação de d_type para otimizar as chamadas estatísticas desnecessárias. Ou seja, se FTS_NOSTAT estiver em vigor e não estivermos seguindo links simbólicos (FTS_PHYSICAL) e d_type indicar que isso énãoum diretório, então não precisaremos statá-lo. Se issoéum diretório, então (atualmente) nós o declaramos independentemente, para obter números de dispositivos e inodes. Algum dia poderemos otimizar isso também para diretórios onde d_ino é conhecido por ser válido.
Então, eles pensaram na otimização que você descreve, mas ela não foi implementada.
Responder2
A página de manual citada paraobter dentesé específico do Linux e não se aplica a todos os tipos de sistemas de arquivos (por exemplo, a página do manual não mencionaprocfsounfs), enquanto GNUencontrarnão é específico da plataforma (sua página de manual menciona o SELinux, que é sem dúvida um recurso útil a ser levado em consideração). Istopoderiaser otimizado para este caso especial também.
Mesmo que o recurso esteja disponível, a página de manual recomenda:
Todos os aplicativos devem lidar adequadamente com um retorno de
DT_UNKNOWN.
Ou seja, a informação, se disponível, pode ser útil, mas não é garantido que esteja presente.
Com todas essas desvantagens, os desenvolvedores findpodem não perceber a necessidade dessa otimização. Um usuário motivado poderia se aprofundar no código-fonte para ver como fazer isso e propor uma mudança ifdef adequada.
@Nate Eldredgeobserva que alguéminiciadoNessa direção. O findmanual afirma em7.2 Otimização d_type
Quando esse recurso está habilitado, find aproveita o fato de que em alguns sistemas readdir retornará o tipo de arquivo em struct dirent.
O recurso foimencionado pela primeira vezem
2005-01-17 James Youngman <[email protected]>
* configure.in, find/defs.h, find/find.c, find/parser.c, find/pred.c, find/tree.c, find/util.c:
Implemented d_type optimisation but not working correctly, so currently disabled
Mais tarde, foirevisado para usar gnulibpara apoiar isso:
2010-04-08 James Youngman <[email protected]>
Adopt the use of the gnulib module d-type.
* import-gnulib.config (modules): Import the d-type module.
* configure.ac: Remove old struct dirent.d_type detection logic
(since we now use the gnulib macro from the d-type module for
this).
A propósito, a versão 4.2.2 é bastante antiga (talvez um erro de digitação):4.2.3data de 2004 e é anterior a essas entradas do changelog. A tag de lançamento atual no git é4.5.14(meados de 2014).
Independentemente do status da d_typeotimização, os desenvolvedores estão interessados em reduzir o número de chamadas para stat. Uma nota de4.5.4(10/03/2009) diz, por exemplo:
O executável ftsfind agora também evita chamar funções stat() para descobrir o número do inode de um arquivo, se já lemos essas informações no diretório. Isso fornece uma aceleração, mas apenas para um conjunto restrito de comandos como "find. -inum 4001". Esta correção está listada abaixo como bug #24342.
Em resumo: OP perguntou
Por que é necessário for stat independentemente de -L, -H ou qualquer outra opção.
A razão é que é um caso especial que é problemático para fazê-lo funcionar perfeitamente, em vez de statpara todos os cenários onde findisso pode ser necessário, e que leva tempo para fazer isso.