rm não apagando arquivo, acha que é um diretório

Question

Eu tenho um disco rígido com o Windows carregado ligado à minha máquina Linux para fazer o backup de algumas das informações. Desejo excluir uma das pastas "arquivos temporários da Internet" e excluí todas, exceto uma delas. Ele retornou um erro com (sendo o caminho que leva através de alguns diretórios):

rm: cannot remove '<path>/dorothy[1].js': Is a directory

Eu então usei cd para chegar onde o arquivo estava e corri:

rm -rf dorothy[1].js

Ele retornou sem erro, mas se eu ls ainda aparecer no diretório. Eu também tentei usar esses dois métodos de removê-lo também, mas sem sucesso (com < inode > sendo o inode do nome do arquivo).

ls -i  
find . -inode <inode> -delete  
find . -inode <inode> -exec rm {} \.

Eu tentei fazer cd dorothy[1].js , o que funcionou. Uma vez dentro eu usei ls que retornou isso:

ls: reading directory.: Input/output error

Então, como eu excluo isso?

    

Answer 1

Você tem um sistema de arquivos NTFS. Nesse caso, você não pode corrigir com segurança o problema em nada, exceto em uma máquina Windows. (O código Linux é bom, mas não posso recomendar que você confie nele para consertar um sistema de arquivos externo.)

Pegue o disco em seu sistema Windows e execute CHKDSK /F Q: , ou qualquer outra letra de unidade que tenha sido atribuída. Em seguida, tente excluir o arquivo. Se isso falhar, você precisará esperar por CHKDSK /R Q: , o que pode levar muitas horas para ser executado.

    

Answer 2

Consulte o comentário de Mat.

Chegou a hora do fsck.

A situação que você descreve é rara. Parece que você tem pelo menos dois inodes apontados para dorothy [1] .js + a entrada de diretório para um inode está corrompido + acha que está apontando para um diretório.

Isso nunca deve acontecer, a menos que você esteja usando código dev / beta para um sistema de arquivos.

Primeiro execute fsck. Em seguida, verifique se você está executando um código de sistema de arquivos estável, o que provavelmente é. Então, o próximo passo é olhar para qualquer código customizado que tenha sido escrito e que esteja furando (termo técnico) na estrutura do diretório físico no disco (shudder).

Além disso, o nome do seu arquivo é interessante, pois contém caracteres '[]' que se expandem para alguma forma de expressão regular em muitos casos. Isso pode ou não ter nada a ver com a sua situação.

Se depois de um fsck tudo funcionar + o problema ocorrer novamente, é provável que você depure por muito tempo começando postando sua versão do kernel + todos os pacotes de software instalados em seu sistema.