Eu estava limpando uma pasta de música na minha unidade externa e encontrei um diretório que não posso excluir, não importa o que eu tente.
Se eu colocá-lo na lixeira via GUI
A operação não pode ser concluída porque o item "pasta" está em uso.
Se eu usar rm -rf
para removê-lo via terminal
$ rm -rf folder/
rm: folder/: Directory not empty
Se eu usar ls -la
para verificar seu conteúdo
$ ls -la
total 512
drwxrwxrwx 1 user staff 131072 Jan 3 2017 .
drwxrwxrwx 1 user staff 131072 Jan 3 2017 ..
Se eu usar rm -i *
dentro da pasta
$ rm -i *
rm: 03 - Ēlusion.mp3: No such file or directory
Se eu usar sudo lsof +D folder/
para verificar se algum arquivo foi aberto
Nada retorna na saída do programa.
Se eu usar o Utilitário de Disco para reparar discos e volumes (primeiros socorros)
A verificação de integridade foi aprovada e nenhum reparo foi iniciado.
Se eu reiniciar o macOS
O problema persiste.
Informação adicional:
Posso mover a pasta dentro da unidade, mas não para outra unidade.
Eu posso renomear a pasta.
ls -i *.mp3
retornals: 03 - Ēlusion.mp3: No such file or directory
, o mesmo querm -i *.mp3
.O arquivo não aparece no Finder, é uma parte confusa, qualquer que seja o problema de exibição do nome de arquivo que o Terminal possa ter (eu sempre o defino
Unicode - UTF-8
), acho que há mais força em jogo.
Em resposta a perguntas, não, ls -ib
não retorna nada.
$ ls -i
$ ls -ib
$ ls -laib
total 512
2762318 drwxrwxrwx 1 user staff 131072 Jan 3 2017 .
2685260 drwxrwxrwx 1 user staff 131072 Jan 3 2017 ..
Então, aparentemente, há algo nele, mas ls -la
não foi possível vê-lo, enquanto rm -i
está sendo estranho com o nome do arquivo?
get info
via menu de contexto da GUI confirmou que há 1 item na pasta, mas com zero byte e certamente não aparece no localizador.
Não tenho certeza do que fazer neste momento. Ajuda muito apreciada!
(Usando 10.13.4 + ExFAT na unidade externa)
fonte
ls -b
mostrar o arquivo? Nesse caso, você podels -bi
obter o inode e seguir a resposta abaixo ou, alternativamente, apenas copiar o nome do arquivo na-b
saída.ls -bi *.mp3
mostre o mesmo resultado, como mostrado no OP.Respostas:
O problema parece ser causado por um arquivo chamado 03 - usionlusion.mp3 localizado dentro do diretório chamado folder .
Como o Terminal.app é incapaz de renderizar sinais diacríticos nos nomes de arquivos - bem, está, mas está além do escopo de fornecer a solução mais simples para você -, oculta sua falha ocultando o nome do arquivo (algo inédito por mim até agora ; talvez as alterações do High Sierra em /.file, /.volfs e inodes de 64 bits? Espere - não importa; sua edição da sua pergunta me diz que eu o entendi mal.) De qualquer forma, a existência do arquivo é conhecida, juntamente com o irônico alegação do Finder de que ele não existe. Obviamente, sim. Veja como mudar isso:
Primeiro, determine o número do inode do arquivo. No Terminal.app,
cd
no diretório "folder" e emita este comando:ls -i *.mp3
Copie a sequência numérica do inode fornecida na coluna esquerda da resposta, que será algo como
12345678 03 - E ̄lusion.mp3
- e coloque-o neste comando, que o renomeará para algo que o terminal possa renderizar corretamente:
find . -inum 12345678 -exec mv {} deletemenow \;
- exibindo o arquivo "deletemenow" na pasta "folder", dos quais você pode descartar da maneira que melhor lhe convier.
fonte
$ ls -i *.mp3
, ele retornals: 03 - Ēlusion.mp3: No such file or directory
.ls -i
dentro do diretório para impedir que a expansão do curinga do shell interfira?Levei muito tempo para chegar a este resumo, mas acho que é a resposta definitiva.
A causa do meu problema é bem conhecida :
Historicamente (não tão antigo, antes da era 10.11), o OS X + HFS + aplica o formulário NFD em todos os nomes de arquivos e você obterá apenas o resultado NFD de comandos e chamadas do sistema.
Então, as coisas começam a mudar; em 10.11, alguns resultados de chamadas do sistema são normalizados para NFC , o que o alinha com o Windows e Linux, mas às custas de quebrar alguns programas que esperam NFD no OS X.
Mas desde a introdução do macOS 10.13 + AFPS, o comportamento muda novamente: a Apple decide que deseja normalizar para NFD nas chamadas de exibição e do sistema , mas deixe os nomes de arquivos originais como estão (para que NFC e NFD sejam suportados, mas se você selecionar o nome do arquivo no Finder ou o
ls
resultado da cópia no Terminal, você obtém o formulário NFD).Isso é ótimo, até você colocar um arquivo com o nome de arquivo NFD em uma unidade externa usando exFAT (como o único formato cross-macOS / Windows com suporte para tamanho de arquivo de 4 GB +): o macOS 10.13 de alguma forma acredita que seu arquivo deve estar no formato NFC, então deu um fora.
Na verdade, aqui está um teste rápido, eu tenho uma pasta no Windows na minha unidade exFAT com 3 arquivos:
test.mp3
Ēlusion.mp3
(Ē
em NFC)03 - Ēlusion
(Ē
em NFD)(Você pode copiar o unicode exato aqui )
Quando eu os montei no meu macOS, é isso que eu vejo:
e
ls -laib
resultado:Como você pode ver, o arquivo NFC está presente, mas está faltando o arquivo NFD.
Mesmo se você estiver ciente do problema NFC / NFD no OS X , talvez não espere que a unidade externa exFAT enfrente esse problema da maneira oposta (a NFC está boa, mas a NFD está acesa).
Mas o que poderia ter causado meu arquivo de música a usar o nome do arquivo NFD em primeiro lugar:
Eu poderia ter copiado o arquivo via unidade de rede ou TeamViewer, e tudo ficaria bem, mas o exFAT está acionando esse bug no macOS.
Lições:
fonte
Error 36
e faça uma pesquisa na Web por algo como "mover arquivos para a frente e para trás do Windows Mac Error 36" para obter mais informações sobre a separação de atribuições de arquivos em sistemas não HFS. Esse foi (outro) problema conhecido de nomeação de arquivos do MacOS / OS X desde a chegada do Sistema 10.6. Entre a normalização Unicode e a separação de atributo dot_underscore, você experimentou um erro duplo. Duvido que o comando dot_clean tenha uma chance.