Eu tenho uma pasta no meu Mac chamada "␀␀␀␀HFS + dados particulares". Eu estou tentando excluí-lo, mas contém um monte de caracteres estranhos que estão bloqueando unlink, rm e mv, tornando-se difícil removê-lo e seu conteúdo. Eu tentei chicotear algum código para chamar unlink () diretamente apenas no caso de binários unlink / rm / mv estarem fazendo algumas outras coisas - mas não, unlink () não pode analisar este caractere.
Eu usei echo e od para descobrir qual personagem é essa:
ashleyharvey@Trinity:~/Desktop/test$ echo -e "␀" | od -t oC -An
342 220 200 012'
Eu procurei 342 aqui: link - e descobri que ele faz parte do conjunto Latin-1. Eu tentei iconv para convertê-lo em UTF-8:
ashleyharvey@Trinity:~/Desktop/test$ iconv -f latin1 -t utf-8 "␀␀␀␀HFS+ Private Data"
iconv: ␀␀␀␀HFS+ Private Data: I/O error
Então, como eu excluo essa pasta? Posso passar códigos hex / oct para rm ou mv ou algo assim? Eu tentei tudo que eu posso pensar, incluindo rm *, invocando sudo, etc O problema é que desvincula as bobinas desse caractere, então eu preciso mudar esse caractere de alguma forma. Eu também estava pensando em instalar o Debian em uma VM e dar a ele acesso a esta pasta para que eu pudesse tentar a partir daí, caso isso seja um problema com as ferramentas que eu tenho no meu ambiente OS X.
EDITAR: Eu tentei isso:
ashleyharvey@Trinity:~/Desktop/test$ echo -e "␀␀␀HFS+ Private Data" | od -t oC -An
342 220 200 342 220 200 342 220 200 110 106 123 053 040 120 162
151 166 141 164 145 040 104 141 164 141 012'
ashleyharvey@Trinity:~/Desktop/test$ echo "200200200063300216145041412" | xargs rm
rm: 342220200342220200342220200110106123053040120162151166141164145040104141164141012: No such file or directory
ashleyharvey@Trinity:~/Desktop/test$ echo "2"
2
EDIT2: mostrando o erro unlink ()
ashleyharvey@Trinity:~/Desktop/test$ unlink test3.txt
ashleyharvey@Trinity:~/Desktop/test$ unlink "␀␀␀␀HFS+ Private Data/1.txt"
unlink: ␀␀␀␀HFS+ Private Data/1.txt: Invalid argument
ashleyharvey@Trinity:~/Desktop/test$ cd "␀␀␀␀HFS+ Private Data/"
ashleyharvey@Trinity:~/Desktop/test/␀␀␀␀HFS+ Private Data$ unlink 1.txt
unlink: 1.txt: Invalid argument
EDIT3: mostrando que não é um problema do sistema de arquivos HFS + /, mas sim um problema de nome de arquivo
ashleyharvey@Trinity:~/Desktop/test$ mkdir "␀␀␀␀testTest"
ashleyharvey@Trinity:~/Desktop/test$ rm -r "␀␀␀␀testTest"
rm: ␀␀␀␀testTest: Invalid argument
EDIT4: isso pode ser um progresso ... Eu vou mexer com a localidade seguinte.
ashleyharvey@Trinity:~/Desktop/test$ ls | grep -i *test* | xxd
0000000: e290 80e2 9080 e290 80e2 9080 7465 7374 ............test
0000010: 5465 7374 0a Test.
ashleyharvey@Trinity:~/Desktop/test$ rm -r $'\xe2\x90\x80\xe2\x90\x80\xe2\x90\x80\xe2\x90\x80\x74\x65\x73\x74\x54\x65\x73\x74\x0a'
rm: ␀␀␀␀testTest
: No such file or directory
Follow-up to this: nope, false hope. I dropped the \x0a on the end and it 'worked'... kind of.
ashleyharvey@Trinity:~/Desktop/test$ rm -r $'\xe2\x90\x80\xe2\x90\x80\xe2\x90\x80\xe2\x90\x80\x74\x65\x73\x74\x54\x65\x73\x74'
rm: ␀␀␀␀testTest: Invalid argument
Você tentou simplesmente renomear a pasta para outra coisa e excluí-la?
Um método que funcionou para mim foi o live boot em um ambiente Linux via CD / USB, desmontar o drive com o diretório / arquivo chamado 'odd', ENTÃO excluí-lo. Esse método funciona na maioria das vezes, não em todos, para mim.
De acordo com o link , essa pasta é usada para o funcionamento interno do sistema de arquivos. Você provavelmente não pode apagá-lo e, mesmo se você puder, provavelmente o seu sistema de arquivos será bloqueado.
Eu sei que isso já foi resolvido para o OP, mas para qualquer um que tropeçar nessa questão, este parece ser um problema apenas do 10.11 El Capitan. Eu tentei e foi capaz de excluir arquivos com esse caractere no OS X 10.4 Tiger e OS X 10.10 Yosemite, por isso, muito provavelmente funciona nos outros.
Apenas uma informação:
A pasta "␀␀␀␀HFS + Private Data" é uma pasta especial do HFS + que é usada para conter os dados de arquivos reais e metadados para arquivos com link físico.
Portanto, várias entradas de diretório apontam para um 'arquivo' nesse diretório oculto, que por sua vez tem os dados e os atributos reais dos arquivos anexados.
Ele tem alguns atributos especiais, como os quatro caracteres ZERO no nome, bem como alguns outros bits em seus meta-dados para tornar muito improvável que seja "visto" pelo usuário final em uso normal.
Quando encontrado em algum backup (sem cópia ativa) como uma pasta visível, você pode removê-lo com segurança, se o sistema permitir (talvez depois de renomear de baixo nível com um editor hexadecimal ou outra ferramenta.
Existe um arquivo oculto similar chamado ".HFS + Dados do Diretório Privado" usado para armazenar informações de link físico em pastas.
Parece que há uma (aposentada?) especificação aqui :
Indirect node files exist in a special directory called the metadata directory. This directory exists in the volume's root directory. The name of the metadata directory is four null characters followed by the string HFS+ Private Data. The directory's creation date is set to the creation date of the volume's root directory. The kIsInvisible and kNameLocked bits are set in the directory's Finder information. The icon location in the Finder info is set to the point (22460, 22460). These Finder info settings are not mandatory, but they tend to reduce accidental changes to the metadata directory. An implementation that automatically follows hard links should make the metadata directory inaccessable from its normal file system interface.
Note:
The case-insensitive Unicode string comparison used by HFS Plus and case-insensitive HFSX sorts null characters after all other characters, so the metadata directory will typically be the last item in the root directory. On case-sensitive HFSX volumes, null characters sort before other characters, so the metadata directory will typically be the first item in the root directory.
A semântica POSIX permite que um arquivo aberto seja desvinculado (excluído). Esses arquivos abertos, mas não vinculados, são armazenados em volumes HFS Plus, como um link físico. Quando o arquivo aberto é excluído, ele é renomeado e movido para o diretório de metadados. O novo nome é a sequência "temp" seguida pelo ID do nó do catálogo convertido em texto decimal. Quando o arquivo é fechado, esse arquivo temporário pode ser removido. Todos esses arquivos temporários podem ser removidos ao reparar um volume HFS Plus não montado.
Repairing the Metadata Directory
When repairing an HFS Plus volume with hard links or a metadata directory, there are several conditions that might need to be repaired:
Opened but deleted files (which are now orphaned).
Orphaned indirect node files (no hard links refer to them).
Broken hard link (hard link exists, but indirect node file does not).
Incorrect link count.
Link reference was 0.
Opened but deleted files are files whose names start with "temp", and are in the metadata directory. If the volume is not in use (not mounted, and not being used by any other utility), then these files can be deleted. Volumes with a journal, even one with no active transactions, may have opened but undeleted files that need to be deleted.
Detecting an orphaned indirect node file, broken hard link, or incorrect link count requires finding all hard link files in the catalog, and comparing the number of found hard links for each link reference with the link count of the corresponding indirect node file.
A hard link with a link reference equal to 0 is invalid. Such a hard link may be the result of a hard link being copied or restored by an implementation or utility that does not use the permissions in catalog records. It may be possible to repair the hard link by determining the proper link reference. Otherwise, the hard link should be deleted.
Gastei algum tempo com o Suporte da Apple sobre isso e eles me disseram que a única resposta era fazer um backup do Time Machine do meu volume, limpar o volume original, criar uma nova conta de usuário e depois copiar todos os meus arquivos manualmente Backup do Time Machine. Percebendo o trabalho que isso implicaria em restaurar minha conta maravilhosamente complexa com todas as minhas preferências, configurações, autorizações de software, scripts, utilitários úteis, etc, eu não queria fazer isso, então tive outra idéia que funcionou para mim.
Eu trabalhei que eu poderia mover a pasta imediata acima do arquivo undeleteable, então eu encurralei todos os arquivos que eu tinha com os caracteres nulos que nada me permitiria deletá-los em outra pasta, e então criei um Carbon Copy Cloner clone do meu HDD inteiro de inicialização, mas excluindo a pasta com o undeleteables. Eu então inicializei neste disco, reformatei meu disco original e restaurei o clone, sem os arquivos undeletable.
Quando alguém trabalha como fazer com que os diversos sistemas operacionais baseados em Unix lide com esses nomes de arquivos, todos ficaremos muito felizes, mas, enquanto isso, a CCC irá me resgatar.