Estou completamente intrigado com um problema com um único arquivo de texto simples em meu sistema fedora 12. Usei um software conhecido em bioinformática, maker, para produzir muitos arquivos de texto simples e um deles parece estar "inacessível".
Particularmente, meu arquivo nomeado Clon1918K_PCC1.gffé listado quando utilizo ls, ls -a, ls -licomandos ... mas quando tento acessá-lo por cat, vim, cp, lsetc aparece sempre o mesmo erro Clon1918K_PCC1.gff: No such file or directory.
Porém, quando copio todos os arquivos com cp *.gffou cp *este arquivo ele também é copiado.
Também tentei abri-lo com o nautilus sem problemas e em um dos dois casos quando copiei o conteúdo para outro arquivo com o mesmo nome o problema desapareceu. Curiosamente neste caso o arquivo estranho não é reescrito e aparecem 2 arquivos exatamente com o mesmo nome, um deles acessível e outro inacessível. Procurei por personagens ocultos, mas tudo parece bem.
Alguém tem alguma ideia sobre esse caso estranho?? Obrigado!
Responder1
Você não pode ter dois arquivos com o mesmo nome no mesmo diretório. Os nomes dos arquivos são, por definição, chaves exclusivas.
O que você tem é quase certamente um personagem especial. Eu sei que você os verificou, mas como exatamente? Você poderia dizer algo como ls *gff | hexdump -Cdescobrir onde estão os caracteres especiais. Qualquer byte com o bit alto definido (ou seja, valores hexadecimais entre 80e FF) será uma indicação de que algo deu errado. Qualquer coisa abaixo 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 no ASCII dos EUA, 1 e l muitas vezes podem ser semelhantes. Então, você tem o C do cirílico (U + 0421), o grego Lunate Sigma (U + 03F9, também exatamente como um C), cirílico / grego 'o' minúsculo, etc. Existem alguns caracteres Unicode invisíveis que podem estar lá.
Explicação:por que o bit alto significa que algo deu errado? O nome do arquivo 'Clon1918K_PCC1.gff' parece ser 100% ASCII dos EUA de 7 bits. Colocá-lo hexdump -Cproduz isto:
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 bytes estão abaixo 0x80(8º bit limpo) 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 tradicionais caracteres ASCII dos EUA de 7 bits. Os codepoints U+0080 e superiores representam outros caracteres e são codificados como dois a seis bytes em UTF-8 (no Linux, tente man utf8obter 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 (ou seja, o caractere hexadecimal ASCII 41, Unicode U+0041, é codificado como um byte único 41). Codepoints ≥ 128 são codificados como dois a seis bytes,cada um dos quais tem o oitavo bit definido. A presença de um caractere não-ASCII pode ser facilmente detectada por estesem 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 GREEK SMALL LETTER OMICRON' que se parece com isto: 'ο'. hexdump -Centão produz isto:
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 sequência UTF-8 ce bf, cada byte com seu 8º bit definido. E este é o seu sinal de problema neste caso. Além disso, observe como hexdump, que decodifica apenas ASCII de 7 bits, falha ao decodificar o único caractere UTF-8 e mostra dois caracteres não imprimíveis ( ..).
Responder2
tente renomear o arquivo com nautilus, mas digite o nome desejado (não copie e cole). Isso certamente deve remover quaisquer caracteres especiais. Pode até ser um espaço antes/depois do nome do arquivo que é invisível para você, mas visível para o sistema operacional e os programas. Eu normalmente uso mc para lidar com nomes de arquivos realmente estranhos.
Responder3
Você já considerou a presença de um rootkit? Era uma vez, tive acesso a uma máquina Solaris que tinha um rootkit instalado. Arquivos chamados '*01' não eram visíveis com ls *01ou ls -altr, mas apareciam com um echo *01. A instalação do rootkit foi alterada ls(e de vários outros executáveis) para que certos arquivos e processos não aparecessem nas circunstâncias normais. Sua descrição se parece muito com o rootkit que encontrei.
Responder4
Caso alguém se depare com isso e leia as outras respostas... Vocêpoderiapule muitos obstáculos ou jogue com curingas, como dizem algumas das respostas, ou apenas use ls -b- lembro-me disso como "binário".
A conclusão da 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 aspas shell-escape para lsgerar uma string pré-citada conveniente para outros comandos. 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'$'\t\033''file'
sauer@lightning:/tmp/test> mv -v 'a'$'\t\033''file' regular_filename
renamed 'a'$'\t\033''file' -> 'regular_filename'