“find:.: Nenhum tal arquivo ou diretório” enquanto estiver usando find no diretório atual

Question

O comando Localizar parece não funcionar de todo. Por exemplo, eu estou em um diretório onde há absolutamente arquivo chamado index.php e eu executo isso:

[root@server htdocs]# find . -name "index.php"
find: .: No such file or directory

Eu sempre recebo este erro de arquivo ou diretório.

Não importa qual caminho eu defino ou o arquivo que eu pesquiso, sempre recebo esse erro. Tenho certeza de que estou negligenciando algo muito simples. Alguém pode apontar o que estou fazendo errado?

[root@server htdocs]# pwd
/srv/www/htdocs
[root@server htdocs]# type -a find
find is /usr/bin/find
[root@server htdocs]# ls -la | grep index.php
-rw-rw-r--  1 andris users  413 Sep  1  2013 index.php
[root@server htdocs]# find . -name "index.php"
find: .: No such file or directory
[root@server htdocs]# find .
.
find: .: No such file or directory

[root@server htdocs]# stat .
  File: '.'
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: ca00h/51712d    Inode: 155686      Links: 12
Access: (0775/drwxrwxr-x)  Uid: (  504/  andris)   Gid: (  100/   users)
Access: 2014-06-17 19:37:22.000000000 +0000
Modify: 2014-06-08 21:06:16.000000000 +0000
Change: 2014-06-08 21:06:16.000000000 +0000

[root@server htdocs]# find --version
GNU find version 4.2.27
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION SELINUX

strace find . output: link

[root@server htdocs]# find . -noleaf -name "index.php"
find: .: No such file or directory

    

Answer 1

De acordo com a sua saída strace , e não tenho idéia do motivo, os nomes dos arquivos prefixos da função open() com /proc/ :

open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
getdents64(4, /* 21 entries */, 32768) = 664
getgid32() = 0
stat64("/proc/index.php", 0xbfc53bd0) = -1 ENOENT (No such file or directory)
getgid32() = 0
stat64("/proc/.svn", 0xbfc53bd0) = -1 ENOENT (No such file or directory)
getgid32() = 0
stat64("/proc/init-dist.php", 0xbfc53bd0) = -1 ENOENT (No such file or directory)
getgid32() = 0
stat64("/proc/landing-page.html", 0xbfc53bd0) = -1 ENOENT (No such file or directory)
getgid32() = 0
[...]
stat64("/proc/js", 0xbfc53bd0) = -1 ENOENT (No such file or directory)
getgid32() = 0
stat64("/proc/extras", 0xbfc53bd0) = -1 ENOENT (No such file or directory)
getgid32() = 0
stat64("/proc/sitemaps", 0xbfc53bd0) = -1 ENOENT (No such file or directory)
getdents64(4, /* 0 entries */, 32768) = 0

    

Answer 2

Você pode não ter permissão de execução para seu usuário para o diretório do qual está pesquisando. Tem permissão de leitura e execução?

    

Answer 3

Experimente com o caminho absoluto como:

   sudo find /where/your_file_is/located/ -iname "index.php"

E, como já mencionado, pode ser que você não tenha permissões. O que acontece se você:

ls . 

Seu shell sabe o que fazer com o ponto?

    

Answer 4

Você pode usar

$ find ~/ -type f -name "MYFILE"

A melhor maneira de pesquisar por arquivos ou pastas é:

• updatedb (para atualizar o índice de arquivos do sistema).

• locate Myfile

Answer 5

Estou usando o Red Hat Enterprise Linux Server versão 6.4 (Santiago). Você pode ter certeza de que está usando o achado correto, quer /usr/bin ou /bin , para ter certeza de que o comando find está lá. Se você não pode nem mesmo fazer um man em find , tente alterar seu shell para /bin/ksh ou /bin/bash . Eu descobri que variáveis de ambiente e caminhos podem ficar confusos de vez em quando.

    

Answer 6

Como outros já mencionaram, usar o caminho completo para encontrar o binário pode ajudar. É possível encontrar é aliado com bandeiras adicionais no seu sistema. Digitar \find impedirá que os aliases sejam usados também. Você também pode usar alias para visualizar aliases de comando na sua sessão atual do shell.

    

Answer 7

Eu vejo isso acontecer no Mac quando o diretório está em mídia removível que foi removida e lida desde que a janela do terminal foi aberta. Não consigo explicar por que (provavelmente tem a ver com informações armazenadas em cache quando a sessão de terminal foi iniciada), mas era reproduzível. Apenas reiniciei a sessão do terminal e tudo correu bem.