Arquivo estranho com nome impossível no meu diretório home

4

Eu tenho um arquivo estranho que apareceu no meu diretório pessoal há alguns dias:

ls no bash me dá a seguinte saída:

Âõ(\'e@\Âõ(@\Âõ(,e@ëQ¸[email protected]

Em fish , ls cita os nomes como seguros para shell por padrão e me fornece isto:

''$'725''(\'\''e@\'$'725''(@\'$'725''(,e@'$'753''Q'$'06''[email protected]'

Não consigo excluir esse arquivo no Dolphin porque ele parece não existir. Eu acho que há um bug no Dolphin que não pode funcionar com um nome de arquivo patológico. Consegui excluí-lo com rm na linha de comando e na conclusão da tabulação.

De onde esse arquivo veio? Eu uso o sistema de arquivos EXT4 com a criptografia LUKS no Fedora 25. A partição é um pouco mais antiga, eu criei isso de 2015 a 20 de outubro (por volta daquele mês). Isso é algo que eu deveria me preocupar?

    
por Martin Ueding 14.01.2017 / 21:40

2 respostas

2

Where could this file have come from?

Você está pedindo especulação pura aqui, mas apenas um caminho possível é a corrupção do sistema de arquivos ou do fluxo de dados do terminal.

Um exemplo de corrupção do sistema de arquivos é que o bloco do disco onde o nome do arquivo está armazenado está de alguma forma corrompido, mas de tal forma que todas as suas somas de verificação são compatíveis. (Sem essa última provisão, o sistema de arquivos simplesmente se recusaria a recuperar os dados corrompidos.) Isso pode acontecer devido a RAM ruim, um disco rígido com falha, cabeamento desonesto, raios cósmicos ...

Um exemplo de corrupção de fluxo de dados de terminal é quando se usa uma linha serial RS-232 (ou algo que o emula) ou um dos protocolos relativamente tolerantes contemporâneos ao reinado de RS-232, como Zmodem .

O Zmodem ainda é conveniente nos dias de SSH e scp porque ele oculta os dados do arquivo por meio da conexão que você já possui; você não precisa, de alguma forma, alternar a conexão SSH para o modo SCP ou estabelecer uma conexão SCP separada. O lrzsz package funciona naturalmente com as linhas de comando SSH e Unix.

O Zmodem-over-SSH é especialmente conveniente quando o SSH é inserido através de uma cadeia de dois ou mais hosts, mas existe uma armadilha. Se você usar as opções padrão rz para tentar Zmodem um arquivo binário através do link, é provável que alguma seqüência de bytes no arquivo seja vista como um seqüência de escape ou caractere de controle pelo host SSH intermediário que não percebe que é retransmitindo uma transferência Zmodem, fazendo com que ela interpretasse mal o fluxo de dados, corrompendo a transferência do Zmodem. (A correção, aliás, é usar rz -e para forçar o escape de caracteres de controle.)

Quando algo assim acontece, o fluxo de dados em andamento está sendo mal interpretado, de modo que, de repente, uma transferência de dados pode se transformar em comandos para o shell e se algo nesse fluxo de comando corresponder a um comando real (por exemplo, cat > h34ijth34u8934 ) o shell cria um arquivo com um nome de lixo. No que diz respeito ao shell, você pediu para fazer isso. O shell não sabe que a origem do nome do arquivo "digitado" é um arquivo de spewing do programa sz remoto depois que o programa local rz em que estava falando morreu.

(Sim, isso realmente aconteceu comigo várias vezes.)

Is this something I should worry about?

Depende de como isso aconteceu, o que novamente exige especulação.

    
por 16.01.2017 / 15:19
3

Isto irá mostrar-lhe o inode do arquivo:

ls -lai

Do que você pode excluí-lo:

find . -type f -inum (inode)

... mas aconselharia verificar primeiro o que está no arquivo. Tente executar file :

find . type f -inum (inode) -exec file {} \;

Do que você pode abri-lo com vim da mesma maneira.

    
por 16.01.2017 / 17:26