bash - diretórios terminados em. e os espaços em branco não podem ser removidos

Question

No meu disco rígido externo há dois diretórios, Fun. e Complex_ , em que esse _ é um espaço em branco. Eu não posso esvaziar minha lixeira ou removê-los com rm -rf e eu quero. Nem aparece no Finder no OSX, e não me lembro se eles apareceram no dolphin no linux. Mas eles aparecem no bash.

rm e mv retornam No such file or directory . Contendo pastas pode ser movido e trazer os diretórios especiais com eles, mas eles não podem ser excluídos.

Por que ls pode detectar os arquivos, mas rm e mv não podem? Como posso corrigi-los? Estou usando \_ no arquivo complexo. (_ é espaço em branco).

Editar

Os caracteres não devem ser o problema. Eu fiz "teste". e "test" e não tive problemas em removê-los usando aspas. Mas esses dirs ainda não podem ser removidos. Deve haver algo muito baixo nível errado com os próprios arquivos reais

sagan:Math ptwales$ ls
Complex 
sagan:Math ptwales$ ls -i
ls: Complex : No such file or directory
sagan:Math ptwales$ ls -idF *
ls: Complex : No such file or directory
sagan:Math ptwales$ find . -name * -print0
find: ./Complex : No such file or directory
sagan:Math ptwales$ 

Mesmos resultados com Fun. Acredito que os diretórios pai tenham links para os arquivos e saibam seus nomes, mas os arquivos simplesmente não existem ou estão corrompidos de alguma forma.

A unidade externa está no formato exFAT. Isso seria relevante?

    

Answer 1

rm e mv também podem detectar os diretórios muito bem, mas você digita: rm file , então o shell irá ignorar o espaço em branco.

Existem algumas coisas que você pode fazer para contornar isso. O mais fácil é encapsular o nome do arquivo entre aspas. Outra solução é escapar do caracter especial, por ex. com uma barra invertida

Exemplo:

touch "testfile "

host:/home/username/test>ls -al
total 12
drwx------   2 hennes  users  4096 Sep 26 02:44 .
drwxr-xr-x  34 hennes  users  8192 Sep 26 01:39 ..
-rw-------   1 hennes  users     0 Sep 26 02:44 testfile

Agora, para excluí-los:

rm "testfile " ou

rm testfile\ (observe o espaço em branco após a barra invertida)

Quanto aos nomes de arquivos terminados em um ponto. Eu não consigo reproduzir o problema. Tem certeza que termina em um ponto e não em algum outro caracter especial?

toad:/home/hennes/test>bash --version
GNU bash, version 4.1.10(1)-release (amd64-portbld-freebsd7.3)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

toad:/home/hennes/test>touch Fun.

toad:/home/hennes/test>ls
Fun.

toad:/home/hennes/test>rm Fun.
toad:/home/hennes/test>ls
toad:/home/hennes/test>

Se for outro caracter do que um ponto, leia o Separador de arquivos internos no bash. Você pode configurá-lo para outra coisa, ou apenas usar os comandos sunch como encontrar com -print0. (Exemplo find /path/to/search-name 'SomeFilePattern*' -print0 | some_command )

    

Answer 2

Eu escrevi uma resposta sobre isso para uma pergunta semelhante no Server Fault. A premissa é ligeiramente diferente, mas em grande parte a mesma resposta funciona.

Você pode combinar ls -i (ou stat , que também imprime o número do inode) e find -inum . Isso funciona bem para um pequeno número de arquivos, onde, por algum motivo, a globalização direta de caracteres universais é indesejada. O exemplo abaixo é adaptado para diretórios, enquanto a resposta no Server Fault lida com arquivos, mas o princípio é o mesmo: usar o número de inode para identificar a entrada de diretório para fazer algo com.

Por exemplo:

~$ ls -idF myweirddir
183435818 myweirddir/
~$ find . -inum 183435818 -exec mv -v '{}' 'delete-me' ';'
'./myweirddir' -> './delete-me'
~$ ls -lA delete-me/
... check the contents ...
~$ rm -rf delete-me
~$

Esta resposta também está terminada no Server Fault, com pequenas diferenças e uma variante alternativa com a substituição direta do processo usando o find e o stat, o que provavelmente é isn realmente aplicável na sua situação. Se você gostou da resposta aqui, considere também fazer um upvoting no Server Fault.

    

Answer 3

Isso parece um sistema de arquivos corrompido ou uma implementação de sistema de arquivos com bugs.

Infelizmente, o sistema de arquivos exFAT é mal suportado em sistemas que não são da Microsoft. Se você tem capacidade de usar um sistema de arquivos diferente, por favor, considere isso.

Por favor, verifique a integridade do sistema de arquivos. No Linux, você pode verificar a integridade do exFAT executando exfatfsck . Infelizmente este utilitário não poderá reparar o sistema de arquivos. No Windows (XP com atualização KB955704, Vista SP1 ou mais recente) você pode usar chkdsk , que é capaz de verificar e reparar o sistema de arquivos.

    

Answer 4

Quando há um arquivo com algum nome estranho que você não pode digitar, você pode usar o recurso de seleção do bash:

select f in * .*; do rm -i $f; done