Questão Existem arquivos undeleteable no Linux?


Eu nunca vi isso antes (20 anos de nix). Eu tenho tentado salvar meu disco rígido (detalhes mediante solicitação) e tenho tido bastante sucesso, exceto que existem alguns arquivos que se parecem com isso:

$ ls -al
$ ?????????? ?    ?       ?      ? blah.txt

Este arquivo não é afetado por rm, rm -f, shred, mv, chown, chmod ou qualquer outro comando que eu possa imaginar.

exemplo

# whoami
root

# rm -f blah.txt
rm: cannot remove `blah.txt': permission denied

# ls -la blah.txt
?????????? ?    ?       ?      ? blah.txt

Basicamente o mesmo para todos os comandos neste arquivo.

Alguma ideia?


4


origem


20 anos de Unix e você não viu um sistema de arquivos corrompido e / ou HD quebrado antes? Sortudo. - Janne Pikkarainen
Ah, foi o que achei que poderia ser. Sim, acho que tive sorte assim. O HD não está quebrado, btw. Funciona bem. - bev
Isso geralmente significa que o nome do arquivo está listado no diretório, mas não pôde acessar seu inode. Pode ter um número de inode inválido no diretório ou o inode no disco pode ter sido corrompido. - mark4o


Respostas:


Você pode nos mostrar a saída do 'lsattr blah.txt'? Isso nos diria quais flags especiais esse arquivo definiu.

Você também pode fazer check no dmesg (o registro de mensagens de depuração do kernel) para qualquer coisa nova (execute dmesg duas vezes, antes de tentar remover um arquivo, uma vez depois, e veja se algo novo apareceu na parte inferior do log).

Uma mensagem de corrupção do sistema de arquivos de amostra pode se parecer com isso:

[86777.332361] EXT4-fs (dm-0): error count: 436
[86777.332365] EXT4-fs (dm-0): initial error at 1290174395: ext4_mb_generate_buddy:726
[86777.332367] EXT4-fs (dm-0): last error at 1292151653: ext4_mb_generate_buddy:726
[86777.332419] EXT4-fs (dm-8): error count: 1406
[86777.332423] EXT4-fs (dm-8): initial error at 1290623933: ext4_mb_generate_buddy:726
[86777.332425] EXT4-fs (dm-8): last error at 1292168399: ext4_mb_generate_buddy:726

e indica que ~ 86777 segundos desde a inicialização (esta parte pode não ser mostrada em seu sistema, depende de uma configuração do kernel) houve dois erros relativos ao sistema de arquivos EXT4 na minha máquina de teste.


1



@qdot, obrigado pela dica. Eu não posso tentar ainda porque algo que eu tentei removeu o problema. Eu 'toquei' no arquivo (eu tinha desistido de recuperar dados) e agora o arquivo parece um arquivo normal sem conteúdo. Enquanto ando pelos meus fs, tenho certeza de que verei mais deles (2 até agora), quando vou tentar lsattr e postar o resultado. - bev
@qdot - ok, aqui está a saída: lsattr: Operação não suportada Ao ler sinalizadores em blah.txt. MAS, lsattr não retorna nenhuma informação para qualquer arquivo no meu sistema. Ele diz: lsattr: ioctl inadequado para dispositivo Ao ler sinalizadores em <todos os arquivos>. Então, ou lsattr não funciona em reiserfs ou, meu disco rígido está corrompido, mas parece estar funcionando muito bem. Hmmmmm Olhando para o dmesg agora. - bev
ReiserFS: aviso: is_tree_node: o nível de nó 0 não corresponde ao esperado 1 ReiserFS: sda3: aviso: vs-5150: search_by_key: formato inválido encontrado no bloco 869576. Fsck? ReiserFS: sda3: aviso: vs-13070: reiserfs_read_locked_inode: ocorreu uma falha de E / S ao tentar encontrar dados estatísticos de [265071 265097 0x0 SD] ReiserFS: aviso: is_tree_node: o nível de nó 0 não corresponde ao esperado 1 ReiserFS: sda3: aviso: vs-5150: search_by_key: formato inválido encontrado no bloco 869576. Fsck? - bev
Yah Parece que há um problema com a estrutura do inode. Eu vou rodar o fsck novamente. - bev
Ran fsck --check que agora me diz que há muita corrupção acontecendo e eu preciso rodar o fsck --rebuild-tree. Então, depois de ter feito o backup da minha partição alguns dias atrás, eu corri isso. Eu vou voltar para você no resultado. - bev


Seu sistema de arquivos está corrompido. Um fsck provavelmente ajudaria.

edit: a menos que você esteja usando o ReiserFS, nesse caso o fsck pode corrompê-lo ainda mais ...


7



Essa foi a primeira coisa que fiz. Não retornou nenhum bloco ruim. - bev
Não pode ser outra coisa. Reconsidere essa possibilidade. No entanto, notei que você está usando o ReiserFS. Esteja ciente de que o ReiserFS fsck pode destruir seu sistema de arquivos. Essa é uma das falhas do projeto ReiserFS ... - jlliagre
Uma das falhas de design do reiserfs é que rodar o reiserfsck pode destruir um sistema de arquivos? É bom saber (depois, é claro, eu executei o reiserfsck no meu sistema de arquivos). Vou tentar encontrar documentação sobre isso. Sorte que eu apoiei tudo há 2 dias. Ah, e você estava correto. Eu corri o fsck e ele me mostrou muitos problemas. - bev
A partir de en.wikipedia.org/wiki/ReiserFS: O processo de reconstrução de árvore do fsck do ReiserFS tem atraído muitas críticas: se o sistema de arquivos ficar tão corrompido que sua árvore interna é inutilizável, executar uma operação de reconstrução de árvore pode corromper arquivos existentes ou introduzir novas entradas com conteúdo inesperado - jlliagre
@jlligre - obrigado pelo link. Muito scarey. Eu estou pensando no meu próximo passo. Eu tenho toda a partição de backup. Eu tenho razão para acreditar que o hd físico é ok, a situação atual é devido a mim mexer com 2 hds externos depois que eu tinha feito o backup (embora eu não vejo o que eu fiz isso causou isso). Você sugeriria que eu destruísse a partição e formatasse com ext3? thx pelo conselho. - bev


chattr +i file faz um arquivo completamente protegido contra gravação, até mesmo pelo root. É chamado imutável. Para apagar ou modificar, você primeiro tem que fazer isso mutável novamente chattr -i file.


4



obrigado pela ajuda, infelizmente, não funcionou. Aqui está o que aconteceu: $> chattr -i blah.txt $> chattr: Permissão negada ao tentar declarar blah.txt - bev