Case estranho: arquivo de texto que existe e não existe

Question

Estou completamente perplexo sobre um problema com um único arquivo de texto simples no meu sistema fedora 12. Eu usei um software conhecido em bioinformática, fabricante, para produzir muitos arquivos de texto simples e um deles parece ser "inacessível ".

Particularmente, meu arquivo chamado Clon1918K_PCC1.gff está listado quando eu uso os comandos ls, ls -a, ls -li ... mas quando eu tento acessá-lo por cat, vim, cp, ls etc aparece sempre o mesmo erro Clon1918K_PCC1.gff: No such file or directory .

No entanto, quando copio todos os arquivos com cp *.gff ou cp * , esse arquivo também é copiado.

Também tentei abri-lo com nautilus sem problema e em um dos dois casos quando copiei o conteúdo para outro arquivo com o mesmo nome o problema desaparece. Curiosamente, neste caso, o arquivo estranho não é reescrito e aparecem 2 arquivos com exatamente o mesmo nome, um deles acessível e outro inacessível. Procurei por caracteres ocultos, mas tudo parece ok.

Alguém tem alguma idéia sobre esse estranho caso? Obrigado!

    

Answer 1

Você não pode ter dois arquivos com o mesmo nome no mesmo diretório. Os nomes de arquivos são, por definição, chaves exclusivas.

O que você tem é quase certamente um personagem especial. Eu sei que você verificou por eles, mas como exatamente? Você poderia dizer algo como ls *gff | hexdump -C para descobrir onde estão os caracteres especiais. Qualquer byte com o conjunto de bits alto (isto é, valores hexadecimais entre 80 e FF ) será uma indicação de algo que deu errado. Qualquer coisa abaixo de 20 (decimal 32) também é um caractere especial. Outra dica é a presença de pontos . na coluna de texto à direita de hexdump -C .

Existem vários caracteres que se parecem com caracteres ASCII dos EUA em UTF-8. Mesmo em ASCII dos EUA, 1 e l podem ser parecidos. Então, você tem o C do cirílico (U + 0421), o Sigma Lunático grego (U + 03F9, também exatamente como um C), cirílico / grego minúscula 'o', etc. E esses são apenas os visíveis. Existem alguns caracteres Unicode invisíveis que podem estar lá.

Explicação: por que o bit alto significa algo que deu errado? O nome do arquivo "Clon1918K_PCC1.gff" parece ser 100% ASCII dos EUA de 7 bits. Colocá-lo em hexdump -C produz isso:

00000000  43 6c 6f 6e 31 39 31 38  4b 5f 50 43 43 31 2e 67  |Clon1918K_PCC1.g|
00000010  66 66                                             |ff|

Todos esses valores de byte estão abaixo de 0x80 (8th bit clear) porque são todos pontos de código ASCII dos EUA de 7 bits. Os pontos de código Unicode U + 0000 a U + 007F representam os caracteres ASCII dos EUA de 7 bits tradicionais. Codepoints U + 0080 e acima representam outros caracteres e são codificados como dois a seis bytes em UTF-8 (no Linux, tente man utf8 para obter muitas informações sobre como isso é feito). Por definição, o UTF-8 codifica os pontos de código US-ASCII como eles próprios (isto é, o caractere hexadecimal ASCII 41 , Unicode U + 0041, é codificado como o byte único 41 ). Codepoints ≥ 128 são codificados como dois a seis bytes, cada um dos quais tem o oitavo bit set . A presença de um caractere não-ASCII pode ser facilmente detectada por este sem ter que decodificar o fluxo . Por exemplo, digamos que eu substitua o terceiro caractere no nome do arquivo, "o" (ASCII 6f , U + 006F) pelo caractere Unicode "U + 03FB GREY LETTER OMICRON", que é assim: "ο". hexdump -C produz isso:

00000000  43 6c ce bf 6e 31 39 31  38 4b 5f 50 43 43 31 2e  |Cl..n1918K_PCC1.|
00000010  67 66 66                                          |gff|

O terceiro caractere agora é codificado como a seqüência UTF-8 ce bf , cada byte cujo oitavo bit é definido. E este é o seu sinal de problema neste caso. Além disso, observe como hexdump , que decodifica apenas ASCII de 7 bits, não consegue decodificar o caractere único UTF-8 e mostra dois caracteres não imprimíveis ( .. ).

    

Answer 2

tente renomear o arquivo com o nautilus, mas digite o nome desejado (não copie e cole). Isso certamente deve remover qualquer caractere especial. Pode até ser um espaço após / antes do nome do arquivo que é invisível para você, mas visível para o sistema operacional e para os programas. Eu costumo usar o mc para lidar com nomes de arquivos reais.

    

Answer 3

Já considerou a presença de um rootkit? Era uma vez, eu tinha acesso a uma máquina Solaris que tinha um rootkit instalado. Os arquivos chamados "* 01" não estavam visíveis com ls *01 ou ls -altr , mas apareceram com echo *01 . A instalação do rootkit havia alterado ls (e vários outros executáveis) para que certos arquivos e processos não aparecessem nas circunstâncias usuais. Sua descrição parece muito com o rootkit que encontrei.

    

Answer 4

É provável que exista um caractere “estranho” no nome do arquivo: talvez um espaço, ou um caractere de controle, ou um caractere não-ASCII que se pareça com um caractere ASCII. Como o arquivo é correspondido por *.gff , qualquer charter especial seria antes do . .

Execute LC_ALL=C ls -l --quoting-style=c *.gff para ver uma representação não ambígua do nome do arquivo.

Execute mv -i *.gff Clon1918K_PCC1.gff para renomear o arquivo para um nome conhecido.

    

Answer 5

Não é possível no linux ter dois arquivos com o mesmo nome, residindo no mesmo diretório.

Tente vim o diretório pai e, em seguida, navegue até o arquivo "stranger" e veja, se você puder acessá-lo

    

Answer 6

Tente usar

find . -iname Clon1918K_PCC1.gff

este arquivo pode estar em qualquer subdiretório e não no diretório atual.

    

Answer 7

No caso de alguém se deparar com isso e ler as outras respostas ... Você poderia pular muitos aros ou apostar com curingas como algumas das respostas dizem, ou apenas usar ls -b - Eu me lembro como "binário".

O preenchimento de tabulação no shell deve citar automaticamente o caractere, mas você pode usar algo que não seja o shell (como o Nautilus) ou usar o estilo de citações shell-escape com ls para gerar uma string pré-citada conveniente para outros comandos. Eu usei esse exemplo de arquivo estranho em outra resposta mais longa em outro lugar, mas também é relevante aqui:

sauer@lightning:/tmp/test> ls
a??file
sauer@lightning:/tmp/test> ls --quoting-style=shell-escape
'a'$'\t3''file'
sauer@lightning:/tmp/test> mv -v 'a'$'\t3''file' regular_filename
renamed 'a'$'\t3''file' -> 'regular_filename'