A sequência exata de eventos seria algo como
- crie
foodir
- inicie
find
- find lê o diretório atual, armazena em cache o resultado e, em seguida, itera sobre ele, localizando uma entrada para foodir
- find inicia o comando
exec
para foodir, excluindo foodir - find tenta reciclar em foodir (está no cache interno do find), que não existe mais
- find exibe um aviso de que não foi possível recorrer ao foodir
- o find continua com a próxima entrada (o que, nesse caso, provavelmente é o final da lista de entradas de diretório, portanto, sai depois de ter feito seu trabalho com o melhor de sua capacidade)
Então, o que você está vendo é perfeitamente explicável, ainda que inesperado do ponto de vista externo.
O cache é quase certamente feito para melhorar o desempenho, economizando um número potencialmente grande de chamadas do sistema, bem como um grande potencial de E / S de disco para cada arquivo. Sem um sistema de arquivos transacional, o que é comum, mas não garantido, não há garantia de que você não acertaria problemas como este, mesmo que o Find tenha lido o diretório uma vez para cada entrada; e no caso de sistemas de arquivos não-locais em particular, até mesmo a ordem das entradas pode mudar entre as verificações, portanto você não pode simplesmente acompanhar um índice, mas deve manter o controle de cada diretório entrada que você visitou. Para uma hierarquia de diretórios grande, isso se torna proibitivo muito rapidamente.
Em geral , isso é denominado " condição de corrida ": uma pré-condição para uma mudança de cálculo entre quando o cálculo é feito e quando o valor resultante é usado.
Olhando para a página man do GNU find, há uma opção -ignore_readdir_race
que pode ajudar a suprimir o aviso. No entanto, eu não sei o quanto isso faz para quaisquer outros comandos executados através do find. Dependendo de suas necessidades, isso pode ser suficiente. Você também pode suprimir quaisquer erros e avisos encontrados ao redirecionar seu erro padrão para / dev / null (anexar 2>/dev/null
à linha de comando), mas não é recomendável, pois pode ocultar erros mais sérios. Eu também não sei de imediato como isso iria interagir com qualquer saída de erro do comando invocado.