Removendo o arquivo com caracteres estranhos no nome do arquivo no OS X

Question

Após um erro de memória no meu programa, estou preso com um arquivo com um nome de arquivo estranho. Está sendo bastante resistente a todos os métodos normais para remover arquivos com nomes estranhos.

O nome do arquivo é:

%8BUȅ҉%95d%F8%FF%FF\x0f%8E%8F%FD%FF%FF%8B%B5T%F8%FF%FF%8B%85\%F8%FF%FF\x03%85x%F8%FF%FF%8B%95D%F8%FF%FF%8B%BD%9C%F8%FF%FF%8D\x04%86%8B%B5@%F8%FF%FF%89%85%90%F8%FF%FF%8B%85X%F8%FF%FF\x03%85%9C%F8%FF%FF%C1%E7\x02%8B%8Dx

Eu tentei o seguinte:

• rm *
  → No such file or directory
• rm -- filename
  → No such file or directory
• rm "filename"
  → No such file or directory
• ls -i para obter o número de inode
  → %código%
• No such file or directory
  → stat filename
• zipar o diretório no qual o arquivo está
  → %código%
• exclua o diretório no localizador
  → No such file or directory
• no Python: error occurred while adding "" to the archive
  → error -43 - os.unlink(os.listdir(u'.')[0])
• OSError
  → %código%
• verificado por bloqueios no arquivo com No such file or directory
  → find . -type f -exec rm {} \;

Todas essas tentativas resultam em um arquivo (nome de arquivo longo aqui) não encontrado erro ou erro -43. Até mesmo o No such file or directory .

Eu não encontrei mais opções, então antes de reformatar ou reparar meu sistema de arquivos ( lsof pode ajudar) eu pensei que talvez houvesse algo que eu perdi.

Eu escrevi este pequeno programa em C para obter o número do inode:

#include <stdio.h>
#include <stddef.h>
#include <sys/types.h>

int main(void) 
{
  DIR *dp;
  struct dirent *ep;

  dp = opendir ("./");
  if (dp != NULL)
    {
      while (ep = readdir (dp)) {
        printf("d_ino=%ld, ", (unsigned long) ep->d_ino);
        printf("d_name=%s.\n", ep->d_name);
      }
      (void) closedir (dp);
    }
  else
    perror ("Couldn't open the directory");

  return 0;
}

Isso funciona. Agora tenho o número de inode, mas o no locks normal não funciona. Acho que tenho que usar o ls -i agora.

    

Answer 1

Tente

find . -type f -exec rm {} \;

Você já tentou excluir o diretório pai?

    

Answer 2

Supondo que o sistema de arquivos é algo diferente de JHFS +

Os sintomas podem ser indicativos de um problema de normalização.

No fórum de suporte do ZEVO, NFD: normalização = formD (formulário de normalização D) inclui uma transcrição parcial do painel de discussão no Illumos ZFS Day 2012:

… subtle bugs that, I feel like no-one else would appreciate my pain. Like in the Unicode space there's actually two different ways to store, several characters – like an é on the Mac traditionally is stored as an e and an ´ character. When it's rendered they composite them.

On any other platform … store composite characters … one click, one character.

So on the Mac, without intervention, you can get into some nasty problems because the Finder stores it one way, Terminal chose a different way. So you can actually go into the Finder and create a directory – café – then go into the Terminal and

touch café

then you have two objects – you have a directory and a file with exactly the same name, which is, it leads to all kinds of … (!) … it looks the same but unlike … where you have differentiator, there's nothing, it's like, and in the Finder, depending on the Finder view you get different experiences. Sometimes you see two folders, sometimes you see a folder and a file, sometimes you see one folder. It's like, it's bizarre. So unfortunately …

… there's a formD-explicit setting so, on the Mac we highly recommend and in fact that's the default, you should use formD so then that problem, you can't do that – when you do the touch it'll actually map it back to the correct way.

You pay a little bit of an overhead but you can keep your sanity. It's crazy to have different stacks using different variants of the encoding.

- link em torno de 00:10:33 na linha do tempo.

    

Answer 3

Para mim

find parent-folder -delete

resolveu o problema. Atenção: Isso irá deletar toda a pasta pai, é claro!

    

Answer 4

I couldn't find anymore options, so before reformatting or repairing my filesystem (fsck might help) I thought maybe there is something I missed.

Não, você foi minucioso. Parece que há um problema com uma parte do sistema de arquivos. Você poderia consertá-lo. Ou você pode pensar em qual outra diversão você gostaria de fazer. No entanto, o mais simples é consertá-lo.

Você pode relutar em reparar o sistema de arquivos: existe uma chance muito pequena, mas existente, de que o reparo possa ocorrer de forma catastrófica. A melhor maneira de se proteger é ter todos os dados importantes salvos em backup. Certifique-se de que seus backups estejam em boa forma antes de reparar o sistema de arquivos.

Em seguida, inicie o reparo. Quando você sabe o que fazer, às vezes você só precisa de coragem para prosseguir. Você pode achar que isso é totalmente resolvido em menos de meio segundo. (Ou talvez um pouco mais se houver alguma sobrecarga ... 3 segundos.)

Note que brincar com dados danificados também apresenta risco de causar mais problemas no sistema de arquivos, então se você está tentando ser seguro, então o mais seguro é fazer a checagem preliminar (que você já fez) e então é só tomar cuidado. do problema (depois de verificar os backups).

    

Answer 5

Eu normalmente abro a pasta que o contém no modo dirado do emacs e, em seguida, marque e exclua.