ti-enxame.com

Tentando excluir o diretório com "rm -rf", mas receba a mensagem de que não está vazio

Eu tentei excluir um diretório usando "rm -rf" e estou recebendo a mensagem "Diretório não vazio":

Bens-MacBook-Pro:please benjaminhocking$ ls -lart empty_directory/
total 16
drwxr-xr-x  5 benjaminhocking  staff  170 Aug 27 14:46 .
drwxr-xr-x  3 benjaminhocking  staff  102 Aug 27 15:28 ..
Bens-MacBook-Pro:please benjaminhocking$ rm -rf empty_directory/
rm: empty_directory/: Directory not empty
Bens-MacBook-Pro:please benjaminhocking$ rmdir empty_directory/
rmdir: empty_directory/: Directory not empty

Se eu tentar a mesma coisa usando o Finder (arrastando a pasta para a Lixeira), recebo a mensagem

A operação não pode ser concluída porque o item "empty_directory" está em uso.

Eu tentei fazer xattr -d com.Apple.quarantine, puramente fora de superstição, mas não adiantou.

Um pedaço de contexto provavelmente importante é que esse diretório estava inicialmente em um diretório que deveria ter sido excluído por um comando "make clean" que eu emiti antes do Terminal travar em mim, após o qual pouco mais da metade dos outros programas executando também trancado, incluindo o Skype e, eventualmente, o próprio sistema operacional. Acabei tendo que reiniciar o computador pressionando e segurando a tecla liga/desliga.

Editar para adicionar: Outra informação importante que eu deixei de fora era que isso estava acontecendo em uma pasta criptografada à la encfs. Consegui localizar a pasta correspondente no lado criptografado e excluí-la. Eu ainda não sei porque eu não poderia fazer isso do lado descriptografado de coisas como eu normalmente faço. Deixarei isso sem resposta por enquanto, caso alguém tenha uma boa resposta para isso.

28
Ben Hocking

Reinicie seu computador e execute rmdir(1) novamente.

$ rmdir -r empty_directory/

Se isso não funcionar, tente:

$ rm -rf empty_directory/

Se ainda assim não funcionar, supondo que o OS X tenha lsof(8) pré-instalado, digite:

$ lsof +D empty_directory/

Isso deve informar se algum arquivo desse diretório está sendo usado por algum programa. Eu acho que o sistema de arquivos HFS + não permite a exclusão de arquivos em uso. De qualquer forma, killall(1) quaisquer executáveis ​​que possam estar usando este diretório ou quaisquer arquivos ocultos dentro dele. É provável que o Finder esteja usando um arquivo oculto no diretório empty_directory para armazenar as configurações de exibição de pastas. Espero que isto ajude.

P.S .: Para descobrir se lsof(8) está instalado, digite:

$ lsof

Se a saída se parece com isto, então lsof(8) está instalado no seu sistema.

lsof: /usr/bin/lsof /usr/bin/X11/lsof /usr/share/man/man8/lsof.8.gz

Verifique se há arquivos ocultos e criptografados ou arquivos de chave de criptografia nesse diretório. Estes poderiam ser os culpados.

9
Jonathan Reno

Reparar o disco usando o Utilitário de Disco corrigiu esse problema para mim.

3
Shlok Datye

Eu corri para exatamente este erro ao mesmo tempo, tentando remover um diretório (rm -r dirname). Eu já tinha tentado todas as sugestões que li antes de pesquisar e encontrar este tópico. Eu não sei se pode ter havido quaisquer pontos adicionais não intencionalmente deixados sem referência a partir da questão original, mas no meu caso, a raiz do problema, e a solução foi:

  • o diretório em questão estava em um disco montado em rede

  • qualquer tentativa de ls do Finder ou linha de comando não mostrou nada além de . e ..

  • Eu entrei no servidor de disco de rede através do comando ssh e verifiquei ls -al lá. O resultado mostrou, além de . e .., vários .__filename itens com informações de segurança estendidas (por exemplo, + acrescentado ao modo).

Eu acredito que estes são, ou são semelhantes a, arquivos que eu observei pela primeira vez no Mac OSX há anos atrás, usando cp -R, tar ou cpio para arquivar ou mover grupos de arquivos. Eu tinha deduzido no momento que eles foram usados ​​para redefinir corretamente algumas propriedades do arquivo após a mudança - talvez uid/gid, modo, acls, mtime/utime/ctime, etc; Não tenho certeza - propriedades que não foram sendo redefinidas corretamente por esses comandos antes disso (lembro que o OSX costumava incluir mvmac e cpmac comandos para contornar o problema antes que esses tipos de arquivos .__filename começassem a aparecer ao usar as formas usuais de cp, tar, etc).

Eu nunca encontrei problemas para excluir esses arquivos quando eles foram gravados em uma unidade interna, USB ou Firewire; essa foi a primeira vez que os encontrei em um disco de rede; completamente indetectável do lado do cliente da montagem, mas normal em todos os sentidos quando visto do lado do servidor.

rm -rf dirname de um login no servidor de disco de rede removeu corretamente o diretório junto com seu conteúdo.

Então, há outra resposta para o que vale a pena; outra solução potencial para esse problema se ele aparecer para qualquer um em conjunto com um disco de rede.

2
Ken

Se isso acontecer e você tiver certeza de que deseja excluir tudo, tente usar Sudo rm -rf directory/

2
m1.

Tentei todas as respostas aqui sem resultados. No entanto, consegui mover o diretório usando o comando mv, o que me permitiu continuar.

1
Jeremy Ninnes

A única solução que funcionou para mim foi a partir de https://unix.stackexchange.com/questions/234876/unable-to-delete-a-file-whatever-i-do :

Mova-os para/tmp e reinicie.

As outras opções que eu tentei foram:

  • Utilitário de Disco - Primeiros Socorros.
  • lsof +D bad_file não exibiu saída.
  • Sudo rm -rf
  • Inicializando no terminal de usuário único e rm -rf.
1
Joe

Para o benefício dos leitores:

Cuidado rm -rf em tal caso! Pode criar problemas em outro lugar caso seja um compartilhamento de rede! Você foi avisado!

Em quase todos os casos, se um directory parecer estar vazio, use rmdir directory ou talvez Sudo rmdir directory. Não use rm (ou del no Windows). Se isso não funcionar, você precisa descobrir, o que bloqueia essa solicitação, corrigi-la e, em seguida, tente novamente o rmdir.

Por favor note que eu não conheço o OS-X, mas acho que as coisas lá são muito parecidas com o comportamento do Unix/BSD.

É muito provável que o diretório em questão fosse apenas um ponto de montagem (do encfs) ou residindo em um ponto de montagem que se tornou somente leitura ou preso em algum estado inadequado (o que impediu que o diretório fosse removido) . Se você agora forçar a remoção do diretório, coisas muito ruins podem acontecer.

No bom caso o diretório estava realmente vazio, então removê-lo (destruir a montagem etc.) não causou mais danos. Na pior das hipóteses, não estava vazio, apenas parecia estar, o que significa que você destruiu algo que talvez você não quisesse matar. Isso tudo depende do tipo de montagem, quais drivers estão em uso, etc.

Se as coisas forem implementadas razoavelmente bem, normalmente nada de ruim deve acontecer. No entanto, este não é o caso normal. As coisas já estão em um estado estranho, o que significa: algo está errado, então é melhor não tentar misturar ainda mais! Se algo estiver quebrado, qualquer toque errado pode quebrá-lo.

Por exemplo, se você acertar uma condição de corrida em um compartilhamento de rede, pode ser que seu rm -rf remova dados que são copiados para o compartilhamento por outra pessoa.

No entanto rmdir é garantido para nunca fazer mal, além de remover diretórios realmente vazios. Isso é verdade mesmo no NFS, porque o NFS só garante um comportamento verdadeiramente atômico em mkdir e rmdir, mas em nenhum outro lugar.

PARA SUA INFORMAÇÃO:

Você pode detectar um ponto de montagem usando a ferramenta mountpoint directory. Alternativamente, examine a saída de mount e tente localizar suas montagens lá. Mas cuidado, pelo menos no Linux isso pode mentir. Usando o utilitário mountpoint mais confiável, mas menos conveniente.

Nesse caso você encontrou o ponto de montagem, você pode desmontá-lo e depois remover o diretório, esta é a seguinte seqüência:

umount directory rmdir directory

Se necessário, use Sudo, como de costume.

Notas:

  • Os compartilhamentos de rede podem negar rmdir (e qualquer outra coisa) devido a direitos de acesso.

  • Sistemas de arquivos com defeito podem negar rmdir, dependendo da estratégia de falha. Talvez você veja uma mensagem razoável nesse caso, talvez não.

  • No Linux (e provavelmente em qualquer sistema operacional moderno) você também pode restringir o acesso usando diferentes meios (como montar algo somente leitura, recursos como no SeLinux, etc.). Isso significa que você não vê que é um ponto de montagem e não vê nada de errado, mas simplesmente não funciona. Nesse caso, você precisa procurar por algum outro motivo e pode ser profundamente enterrado no sistema operacional. Depende da ferramenta se você vir alguma mensagem de erro razoável. Talvez também dê uma olhada no syslog/kernel-log como dmesg no Linux (desculpe, eu não sei o equivalente do OS-X).

  • Observe que o bloqueio obrigatório de arquivos também pode ser uma fonte. Enquanto isso é normal no Windows, geralmente não é o caso normal do Unix e eu nunca ouvi-lo para diretórios. Bloqueios de arquivos obrigatórios são cobertos pelo POSIX, mas são opcionais.

  • Muitas vezes, nesses casos, o diretório em questão reside em um sistema de arquivos diferente do que você pensava. Você pode descobrir qual, com o comando df directory (acho que é o mesmo no OS-X).

  • Você pode inspecionar mais profundamente com ferramentas como stat ou statfs no diretório. No entanto, estes são um nível um pouco baixo para pessoas normais, e muitas vezes essas ferramentas estão bem escondidas dos usuários normais.

  • Os diretórios podem ter arquivos com nomes engraçados. Como um arquivo que imediatamente apaga a saída do terminal, parece que não está lá. Tente algo como ls -al | less ou use algo como MidnightCommander mc.

Há trem de outras possibilidades, incluindo insetos, haxors, alienígenas, ou talvez mais coisas exóticas, como fadas. Mas normalmente não é aconselhável começar a procurar lá, em vez disso tente primeiro encontrar o erro ao seu lado, porque "errare humanum est".

1
Tino

Este também poderia ser um caso que eu apenas resolvi em que um link simbólico quebrado estava no lado do servidor e não era visível para o cliente através do CIFS. O link simbólico preencheu um diretório não vazio, mas o cliente não pôde ver ou declarar o symlink com o propósito de limpar o diretório antes de desvincular o diretório. Uma vez que era invisível, criou este paradoxo onde do lado do cliente estava vazio, mas "não vazio" após o desafio por rm. Se você tiver acesso SSH ao servidor, tente um Shell nesse ponto e veja se o diretório está realmente vazio ou se ele pode ter links simbólicos quebrados. Eu consegui fazer isso em um Drobo5N e ele salvou minha bunda.

1
Jon

Tente abrir esse diretório do Windows, pode haver algo não mostrado no Mac OS. Eu tive problema semelhante após uma série de operações de cópia entre Mac e Win PC: o diretório estava vazio, mesmo no terminal, mas no Windows eu encontrei um arquivo do Windows oculto, então eu removi o diretório com sucesso a partir daí.

0
contre_force