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

Tentei excluir um diretório usando "rm -rf" e estou recebendo a mensagem "O diretório não está 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 por superstição, mas não adiantou.

Uma parte do contexto provavelmente importante é que esse diretório estava inicialmente em um diretório que deveria ter sido excluído por um comando "make clean" emitido antes do bloqueio do Terminal, após o qual um pouco mais da metade dos outros programas que eu tinha A execução também trava, 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 rastrear a pasta correspondente no lado criptografado e excluí-la lá. Ainda não sei por que não pude fazê-lo do lado descriptografado das coisas, como normalmente faço. Deixarei isso sem resposta por enquanto, caso alguém tenha uma boa resposta para isso.

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 sido lsof(8)pré - instalado, digite:

$ lsof +D empty_directory/

Isso deve indicar se algum arquivo deste 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 killall(1)qualquer forma, quaisquer executáveis ​​que possam estar usando este diretório ou qualquer arquivo oculto dentro dele. É provável que o Finder esteja usando um arquivo oculto no empty_directorydiretório para armazenar as configurações de exibição da pasta. Espero que isto ajude.

PS: Para descobrir se lsof(8)está instalado, digite:

$ lsof

Se a saída se parecer com isso, ela lsof(8)estará instalada 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 podem ser os culpados.

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

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

Eu encontrei exatamente esse erro ao tentar remover um diretório (rm -r dirname). Eu já havia tentado todas as sugestões que li aqui antes de pesquisar e encontrar este tópico. Não sei se pode ter havido outros pontos, sem querer, intencionais da pergunta 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 lstentativa de linha Finder ou comando não mostrou nada, mas .e..

• Entrei no servidor de disco da rede através do sshcomando e verifiquei ls -allá. O resultado mostrou, além de , .e ..vários .__filenameitens com informações de segurança estendidas (ou seja, +anexadas ao modo).

Eu acredito que estes são, ou são semelhantes, os arquivos que eu notei primeiro Mac OSX criar anos atrás quando se usa cp -R, tarou cpiopara arquivar ou mover grupos de arquivos. Eu deduzi na época que eles eram usados ​​para redefinir corretamente algumas propriedades do arquivo após a mudança - talvez uid / gid, mode, acls, mtime / utime / ctime, etc; Não tenho muita certeza - propriedades que não foram redefinidas corretamente por esses comandos antes desse período (lembro que o OSX costumava incluir mvmace cpmaccomandos para solucionar o problema antes que esses .__filenametipos de arquivos começassem a aparecer ao usar as formas usuais de cp, taretc).

Nunca encontrei problemas para excluir esses arquivos quando eles foram gravados em uma unidade interna, USB ou Firewire; 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 aspectos quando visto do lado do servidor.

rm -rf dirname de um logon no servidor de disco da 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 em potencial para esse problema se ele aparecer para qualquer pessoa em conjunto com um disco de rede.

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

A única solução que funcionou para mim foi em 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 tentei foram:

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

Para o benefício dos leitores:

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

Em quase todos os casos, se um directoryparecer vazio, use rmdir directoryou talvez sudo rmdir directory. Não use rm(ou delno Windows). Se isso não funcionar, você precisa descobrir o que bloqueia essa solicitação, corrigir isso e tentar novamente rmdir.

Observe que eu não conheço o OS-X, mas acho que as coisas são muito semelhantes ao comportamento do Unix / BSD.

É muito provável que o diretório em questão fosse apenas um ponto de montagem (a partir dos encfs) ou residisse em um ponto de montagem que se tornou somente leitura ou travou em algum estado inadequado (o que impediu a remoção do diretório). 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; portanto, removê-lo (destruindo a montagem etc.) não causou mais danos. No caso ruim, não estava vazio, apenas parecia estar, o que significa que você destruiu algo que talvez não quisesse matar. Tudo isso depende do tipo de montagem, de quais drivers estão em uso etc. pp.

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ê encontrar uma condição de corrida em um compartilhamento de rede, pode ser que você rm -rfremova os dados que foram copiados para o compartilhamento por outra pessoa.

No entanto, rmdiré garantido que nunca causará danos, além de remover diretórios realmente vazios. Isso é verdade no NFS, porque o NFS só garante um comportamento verdadeiramente atômico no , mkdire em rmdirnenhum outro lugar.

PARA SUA INFORMAÇÃO:

Você pode detectar um ponto de montagem usando a ferramenta mountpoint directory. Como alternativa, observe a saída mounte tente localizar suas montagens lá. Mas cuidado, pelo menos no Linux isso pode estar. Usando o mountpointutilitário mais confiável, mas menos conveniente.

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

umount directory rmdir directory

Se necessário sudo, use como de costume.

Notas:

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

• Sistemas de arquivos defeituosos 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 o 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 outro motivo e ele pode estar profundamente enterrado no sistema operacional. Depende da ferramenta se você receber alguma mensagem de erro razoável. Talvez também dê uma olhada no syslog / kernel-log como dmesgno Linux (desculpe, eu não conheço o equivalente do OS-X).

• Observe que o bloqueio obrigatório de arquivos também pode ser uma fonte. Embora isso seja normal no Windows, normalmente não é o caso normal do Unix e nunca ouvi falar em diretórios. Os bloqueios de arquivos obrigatórios são cobertos pelo POSIX, mas são opcionais.

• Freqüentemente, 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 statou statfsno 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.

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

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

Este também pode ser um caso que acabei de resolver em que um link simbólico quebrado estava no lado do servidor e não era visível para o cliente pelo CIFS. O link simbólico preencheu um diretório não vazio, mas o cliente não pôde ver ou stat o link simbólico com o objetivo de limpar o diretório antes de desvinculá-lo. Como era invisível, criou esse paradoxo onde, do lado do cliente, ele estava vazio, mas "não vazio", após ser desafiado pela empresa . Se você tiver acesso SSH ao servidor, tente um shell nesse sentido e veja se o diretório está realmente vazio ou se pode ter links simbólicos quebrados. Eu era capaz de fazer isso em um Drobo5N e salvou minha bunda.

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

No terminal:

1. enter sudo su (O prompt da linha de comando deve mudar para algo como sh-3.2#.)
2. navegue até a pasta pai da que você deseja excluir
3. entrar rm -rf TheDirectoryYouWantToDelete

Encontrei esse problema ao tentar excluir uma pasta que um aplicativo estava usando. Quando fechei o aplicativo, removi a pasta sem gerar esse erro. Tente encerrar os aplicativos que possam estar usando.