Por que esse arquivo é oculto quando você executa ls?

Question

EDIT: Eu esqueci completamente sobre este segmento. Acontece que eu tinha um disco rígido ruim. Nós tivemos que reimplantar este servidor para outras necessidades, então eu finalmente consegui substituir o único disco defeituoso e estamos de volta aos negócios.

Durante algumas semanas, não consegui descobrir porque não consegui eliminar este ficheiro específico. Como root eu posso, mas meu script de shell é executado como um usuário diferente. Então eu corro ls -la e não está lá. No entanto, se eu chamo de parâmetro, ele aparece! Com certeza, o dono é o root, por isso não consigo apagar.

Aviso 6535 está faltando ...

[root@server]# ls -la 653*
-rw-rw-r--  1 svn svn  24002 Mar 26 01:00 653
-rw-rw-r--  1 svn svn   7114 Mar 26 01:01 6530
-rw-rw-r--  1 svn svn   8653 Mar 26 01:01 6531
-rw-rw-r--  1 svn svn   6836 Mar 26 01:01 6532
-rw-rw-r--  1 svn svn   3308 Mar 26 01:01 6533
-rw-rw-r--  1 svn svn   3918 Mar 26 01:01 6534
-rw-rw-r--  1 svn svn   3237 Mar 26 01:01 6536
-rw-rw-r--  1 svn svn   3195 Mar 26 01:01 6537
-rw-rw-r--  1 svn svn  27725 Mar 26 01:01 6538
-rw-rw-r--  1 svn svn 263473 Mar 26 01:01 6539

Agora aparece se você ligar diretamente.

[root@server]# ls -la 6535
-rw-rw-r--  1 root root 3486 Mar 26 01:01 6535

Aqui está algo interessante. Então eu peguei esse problema porque no meu script de shell, ele não iria excluir porque 6535 é de propriedade de root. O arquivo realmente aparece depois que eu corro "rm -rf". Eu tentei mais cedo e não conseguiu remover o diretório, uma vez que me disse que o diretório não está vazio. Eu entrei e olhei e com certeza, o arquivo "6535" finalmente apareceu. Não sei por que está fazendo isso.

strace diz o seguinte

#strace ls -la 653* 2>&1 | grep ^open

open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib64/tls/librt.so.1", O_RDONLY) = 3
open("/lib64/libacl.so.1", O_RDONLY)    = 3
open("/lib64/libselinux.so.1", O_RDONLY) = 3
open("/lib64/tls/libc.so.6", O_RDONLY)  = 3
open("/lib64/tls/libpthread.so.0", O_RDONLY) = 3
open("/lib64/libattr.so.1", O_RDONLY)   = 3
open("/etc/selinux/config", O_RDONLY)   = 3
open("/proc/mounts", O_RDONLY)          = 3
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
open("/proc/filesystems", O_RDONLY)     = 3
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
open("/usr/share/locale/en_US.UTF-8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/nsswitch.conf", O_RDONLY)    = 3
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib64/libnss_files.so.2", O_RDONLY) = 3
open("/etc/passwd", O_RDONLY)           = 3
open("/etc/group", O_RDONLY)            = 3
open("/etc/mtab", O_RDONLY)             = 3
open("/proc/meminfo", O_RDONLY)         = 3
open("/etc/localtime", O_RDONLY)        = 3

    

Answer 1

Atualização rápida, tivemos que substituir o servidor por outros motivos. Foi o sistema de arquivos. Tudo está bem agora !!! Obrigado a todos.

    

Answer 2

Isso é um pouco preocupante. Eu verificaria se o arquivo ls não foi modificado comparando com um arquivo válido conhecido. Você pode usar as ferramentas de pacote da sua distribuição para verificar o arquivo em um sistema isolado.

    

Answer 3

Às vezes, os nomes de arquivos recebem caracteres estranhos, como sequências de movimento do cursor. Tente isso para garantir:

ls -lq

Ele deve mostrar pontos de interrogação em vez de caracteres de controle (provavelmente é o padrão, mas pode não ser).

Isso demonstra parcialmente o tipo de problema que pode estar presente:

touch A C
touch B$(tput cuu1)$'\r'
ls -l
ls -lq
ls -l --show-control-chars    # for systems that have that option and default to -q

Eu também tentaria:

type -a ls
alias ls
declare -f ls
md5sum /bin/ls    # compare to a known-good identical system

para ver se um apelido ou função está definido ou para ver se um binário está em um lugar estranho ou foi modificado.

    

Answer 4

Você pode querer fsck esse volume.

    

Answer 5

Eu costumo fazer algo assim se eu acreditar que 'ls' foi modificado ...

python -c "import os; print os.listdir('.')"

É claro que o Python, a Biblioteca C, o kernel ou o sistema de arquivos poderiam também ser modificados, mas normalmente são apenas os utilitários do shell.

    

Answer 6

Você pode verificar exatamente o que o ls está fazendo usando o strace, e isso pode indicar por que ele está evitando mostrar esse nome de arquivo.

strace ls -la 653* 2>&1 | less

veja isso e veja o que está acontecendo.

strace ls -la 653* 2>&1 | grep ^open

A saída ficará assim:

open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib/librt.so.1", O_RDONLY)       = 3
open("/lib/libacl.so.1", O_RDONLY)      = 3
open("/lib/libselinux.so.1", O_RDONLY)  = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/lib/libpthread.so.0", O_RDONLY)  = 3
open("/lib/libattr.so.1", O_RDONLY)     = 3
open("/lib/libdl.so.2", O_RDONLY)       = 3
open("/lib/libsepol.so.1", O_RDONLY)    = 3
open("/etc/selinux/config", O_RDONLY|O_LARGEFILE) = 3
open("/proc/mounts", O_RDONLY|O_LARGEFILE) = 3
open("/selinux/mls", O_RDONLY|O_LARGEFILE) = 3

e se você vir algo como

open("/var/tmp/.../H@ckl1st", O_RDONLY) = 3

tenha cuidado, você foi 0wned ...

Este não é um teste conclusivo, mas é um bom indicador ...

(se você estiver usando o Solaris ou outros sistemas operacionais, você pode precisar usar treliça ou algum outro utilitário semelhante em vez de strace)

(se você estiver usando um shell derivado de csh / tcsh, provavelmente precisará de instruções de redirecionamento diferentes)

    

Answer 7

A teoria do hack é interessante, mas eu tenho uma teoria alternativa. A semântica de exclusão de arquivos Unix manterá o arquivo até que todos os processos tenham fechado identificadores de arquivos abertos apontando para ele. Talvez alguém tenha pausado um check-out / commit do SVN ou um thread de servidor tenha sido desligado. Se reiniciar o processo do SVN (ou Apache) resolver o seu problema, é aqui que colocaria a culpa.

Talvez você possa identificar o processo que ainda usa esse arquivo com lsof | grep 6535 ?