Hoje encontrei algo realmente interessante (pelo menos para mim) em um dos nossos servidores de teste:
Eu posso mudar para um diretório existente a partir do meu diretório de trabalho real usando um caminho relativo, mas esse mesmo diretório não está listado ao usar ls -a .
Aqui está a sessão do shell (como root ):
$ pwd
/you/are/here
$ ls -a
. .. <-- Note: "somedir" is not shown to root
$ echo $CDPATH
$ cd somedir <-- But still: "cd" works fine
$ pwd
/you/are/here/somedir
$ cd ..
$ pwd
/you/are/here
$ ls -a
. ..
Alguém poderia me dizer, como isso é possível? Eu verifiquei: ls é de /bin/ls e pwd é /bin/pwd , ambos do pacote original (quero dizer: não hackeado).
/you é um disco EMC montado (ext3). E somedir existe, pois posso listar o conteúdo dele (existem vários subdiretórios, arquivos). Seu nome não começa com um ponto.
Mais algumas sessões da shell, com mais informações sobre os comandos e a ls output:
root@U-TEST@AT$/bin/ls -ali
total 4
16515074 drwxrwxr-x 2 U8000966 test 2048 Sep 1 07:39 .
16515073 drwxrwxr-x 3 U8000966 test 2048 Apr 27 2006 ..
root@U-TEST@AT$ls -ali somewhere | head -5
total 182
16515075 drwxrwxr-x 43 U8000966 test 2048 Sep 1 07:39 .
16515074 drwxrwxr-x 2 U8000966 test 2048 Sep 1 07:39 ..
16519169 drwxrwxrwx 4 U8000966 test 2048 Jul 25 2007 AAA
16515124 drwxrwxr-x 3 U8000966 test 2048 May 12 2006 BBB
root@U-TEST@AT$type ls
ls is aliased to '/bin/ls $LS_OPTIONS'
root@U-TEST@AT$type pwd
pwd is a shell builtin
root@U-TEST@AT$/bin/pwd
/you/are/here
root@U-TEST@AT$cd somewhere
root@U-TEST@AT$/bin/pwd
/you/are/here/somewhere
root@U-TEST@AT$type cd
cd is a shell builtin
Por favor, note o Total 4 após o primeiro ls -ali . (Não sei se é relevante ...)
Mais alguns testes:
root@UR-TEST@AT$ls
. ..
root@U-TEST@AT$touch somewhere/testfile
root@U-TEST@AT$ls
. ..
root@U-TEST@AT$cp somewhere/testfile ./
root@U-TEST@AT$ls
. .. testfile
root@U-TEST@AT$du .
2 .
root@URBIS-TEST@AT$
E a EMC é: link , mas eles são apenas um provedor de disco caso, com discos rígidos, formatados como ext3.
UPDATE
(Desculpe, mas ontem eu tive que sair)
Eu verifiquei echo * e sua saída é: . .. . Aqui estão os LS_OPTIONS : -a -N --color=tty -T 0 .
Eu tinha verificado a coisa de automount mencionada por Gilles, mas como eu mudei para somewhere e emiti um mount|grep somewhere não havia saída.
Aqui está a saída lsattr e strace como sugerido: link
Zsolt, por favor, tente estas três etapas:
cd / exec bash /usr/bin/find /you/are/here -ls Provavelmente é hora de fsck ...: - (
Mas antes disso, você poderia tentar (depois de fazer backup de qualquer coisa dentro de somedir ): cd /you/are/here && mkdir somedir .% cd /you/are/here && ln somedir newdir (como root).
Verifique também mount | egrep -e 'somedir|you|are|here' para qualquer esquisitice.
No momento em que escrevo isto, você não descartou os efeitos em $LS_OPTIONS . O GNU ls tem algumas opções de ignorar arquivos, e ls -I foo -a ainda ignora foo . Mas o resto da minha resposta assume que você obtém os mesmos resultados sem $LS_OPTIONS .
A linha total 4 não é, de fato, surpreendente. Esse é o número total de blocos usados por . e .. . Se . estiver vazio e .. for pequeno e em um sistema de arquivos cujo tamanho de bloco seja igual a 4 ls (o que é comum: o GNU ls é padronizado para blocos de 1kB e o ext [234] frequentemente usa blocos de 4kB) o total esperado é 0 + 1 * 4 = 4.
Há algo incomum, mas não inédito, acontecendo com o sistema de arquivos em que /you/are/here está ativo. Quando você solicita o conteúdo de /you/are/here (com opendir() e readdir(3) ), o sistema de arquivos responde apenas com . e .. ; ainda assim, quando você assume que /you/are/here/somedir existe, você é informado de que existe. Isso é surpreendente, mas possível comportamento.
Uma possível, mas altamente improvável, explicação é um demônio (como em demônio de Maxwell , não como em programa daemon ) que move somedir para o lugar apenas quando você o acessa e o move para fora do caminho quando você lista o diretório. Assim, a peculiaridade que você observa pode ser causada por um programa comum que, por acaso, faz as suposições certas, não indica nada de errado com o sistema operacional.
Na verdade, o sistema operacional provavelmente está se comportando de maneira peculiar. Um culpado comum é um sistema de automontagem. A maneira como um sistema de montagem automática funciona normalmente é algo assim:
Um diretório, digamos /you/are/here , é configurado como um local para pontos de montagem. Um sistema de arquivos de propósito especial (possivelmente chamado autofs ) é montado lá.
Quando você tenta acessar uma entrada em /you/are/here , digamos /you/are/here/somedir , o driver do sistema de arquivos tenta montar o sistema de arquivos somedir . Por exemplo, ele pode procurar por uma linha como somedir = /dev/foo ou somedir = server:/loca/tion em seu arquivo de configuração e montar o dispositivo indicado ou a localização do NFS como /you/are/here/somedir .
Quando você listar o diretório /you/are/here , verá um subdiretório para cada sistema de arquivos atualmente montado.
Quando você para de usar /you/are/here/somedir , talvez após um atraso, o automounter desmontará somedir . Portanto, somedir não aparece mais na listagem de /you/are/here .
O que "qual ls" ou "alias" mostra? Talvez o seu comando ls esteja sendo substituído por um alias ou algo semelhante? Executar o seguinte pode excluir isso:
/bin/ls -a /you/are/here
Alguns antecedentes:
Um alias tem precedência sobre /bin/ls , mas which ls ainda mostra /bin/ls . Você pode recriar o que estou me referindo a isso:
Crie um script bash chamado ls , mantendo:
#!/bin/bash
echo this is not ls
Crie um alias para o script bash:
alias ls = '~ / ls'
Agora, execute ls . Você deve obter "isso não é ls", mas which ls mostra /bin/ls .
Também pode ser benéfico excluir o autofs / automount.
Depois de analisar as atualizações postadas ...
Talvez LS_OPTIONS contenha um --hide ou --ignore?
~/dirtest$ ls -a
. .. somewhere
~/dirtest$ ls -a --ignore='some*'
. ..
O que faz ...
echo $LS_OPTIONS
... show? Talvez até tente ...
unset LS_OPTIONS
... então execute novamente o comando ls -a.
Pode ser que o LS_OPTIONS esteja sendo configurado em seu .bashrc ou outro arquivo de configuração. (talvez até no nível global, de / etc / bash * (ou qualquer arquivo de configuração apropriado para o shell em questão: .login, .profile, etc)
Você pode tentar outras ferramentas que possam percorrer a árvore de diretórios?
Por exemplo, du -h para obter o tamanho dos diretórios? Qual comportamento você observa ao iniciar isso a partir da raiz da unidade ou de /you/are/here em comparação a /you/are/here/somedir ?
Além disso - você pode criar um arquivo em /you/are/here/somedir ? Em caso afirmativo, ele persiste quando você sai do diretório? A criação de um arquivo faz com que o diretório fique visível no comando ls ?
O seguinte pode ou não ajudar, mas eu gostaria de ver a saída dos dois comandos a seguir:
$ lsattr -av somedir
$ strace ls -a somedir
Talvez algum processo esteja fazendo algo com o diretório. Você já tentou lsof dirname , lsof /path/to/parent/* e lsof dirname/* ?
Que tal stat dirname ?
Que tal readlink -ev dirname ?
Vejo que você fez type ls - o que type -a ls mostra?
O $PATH inclui algo incomum? Inclui . (ponto)?
Qual shell você está usando? Você tentou fazer seu ls dirname original em outro shell (especialmente depois de uma sessão / login completamente nova?
Se você estiver usando um shell com conclusão de tabulação, ele concluirá o nome do diretório?
Você tem acesso a um gerenciador de arquivos, uma GUI ou um modo de texto, como mc (Midnight Commander) ou emacs dired ? Eles podem navegar para dentro e fora desse diretório?
Eu suspeito seriamente que algo esteja corrompido ou hackeado.
A ajuda LS fornece isso, o que pode ser de alguma utilidade.
-a, --all do not ignore entries starting with .
-A, --almost-all do not list implied . and ..
--author with -l, print the author of each file
Neste ponto, parece-me que a coisa mais provável é que seu servidor foi invadido e um rootkit foi carregado, o que impede que o diretório apareça nas listagens. O kit raiz faria isso com um módulo do kernel que conecta ou redireciona as chamadas do sistema readdir e getdents. Se o módulo permanecer residente, provavelmente ele também estará se ocultando em / proc / modules ou por lsmod.
Tags ext3 linux shell filesystems