Estoy completamente desconcertado por un problema con un único archivo de texto sin formato en mi sistema Fedora 12. Utilicé un software conocido en bioinformática, maker, para producir muchos archivos de texto sin formato y uno de ellos parece ser "inaccesible".
En particular, mi archivo nombrado Clon1918K_PCC1.gffaparece cuando uso ls, ls -a, ls -li... comandos pero cuando intento acceder a él mediante cat, vim, cp, lsetc siempre aparece el mismo error Clon1918K_PCC1.gff: No such file or directory.
Sin embargo, cuando copio todos los archivos de cp *.gffeste cp *archivo, también se copia.
También intenté abrirlo con nautilus sin problema y en uno de los dos casos cuando copié el contenido a otro archivo con el mismo nombre el problema desaparece. Curiosamente en este caso el archivo extraño no se reescribe y aparecen 2 archivos exactamente con el mismo nombre, uno de ellos accesible y otro inaccesible. Busqué personajes ocultos pero todo parece estar bien.
Alguien tiene alguna idea sobre este extraño caso?? ¡Gracias!
Respuesta1
No puede tener dos archivos con el mismo nombre en el mismo directorio. Los nombres de archivos son, por definición, claves únicas.
Es casi seguro que lo que tienes es un personaje especial. Sé que los buscaste, pero ¿cómo exactamente? Se podría decir algo como ls *gff | hexdump -Cencontrar dónde están los caracteres especiales. Cualquier byte con el bit alto establecido (es decir, valores hexadecimales entre 80y FF) será una indicación de que algo salió mal. Todo lo que esté debajo 20(32 decimal) también es un carácter especial. Otro indicio es la presencia de puntos .en la columna de texto derecha de hexdump -C.
Hay numerosos caracteres que parecen caracteres ASCII estadounidenses en UTF-8. Incluso en ASCII de EE. UU., 1 y l a menudo pueden parecer similares. Luego, tienes la C del cirílico (U+0421), el Lunate Sigma griego (U+03F9, también exactamente como una C), la 'o' minúscula cirílica/griega, etc. Y esos son solo los visibles. Hay bastantes caracteres Unicode invisibles que podrían estar ahí.
Explicación:¿Por qué el bit alto significa que algo salió mal? El nombre de archivo 'Clon1918K_PCC1.gff' parece ser 100% ASCII estadounidense de 7 bits. Pasarlo hexdump -Cproduce esto:
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 estos valores de bytes están a continuación 0x80(octavo bit claro) porque todos son puntos de código ASCII de EE. UU. de 7 bits. Los puntos de código Unicode U+0000 a U+007F representan los caracteres ASCII estadounidenses tradicionales de 7 bits. Los puntos de código U+0080 y superiores representan otros caracteres y están codificados entre dos y seis bytes en UTF-8 (en Linux, intente man utf8obtener mucha información sobre cómo se hace esto). Por definición, UTF-8 codifica puntos de código US-ASCII como ellos mismos (es decir, el carácter ASCII hexadecimal 41, Unicode U+0041, se codifica como un solo byte 41). Los puntos de código ≥ 128 se codifican entre dos y seis bytes,cada uno de los cuales tiene el octavo bit configurado. La presencia de un carácter no ASCII puede detectarse fácilmente mediante estesin tener que decodificar la transmisión. Por ejemplo, supongamos que reemplazo el tercer carácter en el nombre del archivo, 'o' (ASCII 6f, U+006F) con el carácter Unicode 'U+03FB LETRA MINÚSCULA GRIEGA OMICRON' que se parece a esto: 'ο'. hexdump -Centonces produce esto:
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|
El tercer carácter ahora está codificado como la secuencia UTF-8 ce bf, cada byte del cual tiene su octavo bit establecido. Y esta es su señal de problemas en este caso. Además, observe cómo hexdump, que solo decodifica ASCII de 7 bits, no logra decodificar el único carácter UTF-8 y ..en su lugar muestra dos caracteres no imprimibles ( ).
Respuesta2
intente cambiar el nombre del archivo con nautilus, pero escriba el nombre deseado (no copie y pegue). Sin duda, eso debería eliminar cualquier carácter especial. Incluso podría ser un espacio después o antes del nombre del archivo que sea invisible para usted pero visible para el sistema operativo y los programas. Normalmente uso mc para lidiar con nombres de archivos realmente extraños.
Respuesta3
¿Has considerado la presencia de un rootkit? Una vez tuve acceso a una máquina Solaris que tenía un rootkit instalado. Los archivos llamados '*01' no eran visibles con ls *01o ls -altr, pero aparecían con una extensión echo *01. La instalación del rootkit ls(y de otros ejecutables) había cambiado de modo que ciertos archivos y procesos no aparecían en las circunstancias habituales. Su descripción se parece mucho al rootkit que encontré.
Respuesta4
En caso de que alguien se tope con esto y lea las otras respuestas...podríasalte muchos obstáculos o apueste con comodines como dicen algunas de las respuestas, o simplemente utilícelo ls -b; lo recuerdo como "binario".
La finalización de tabulación en el shell debería citar automáticamente el carácter, pero puede usar algo que no sea el shell (como Nautilus) o usar el estilo de comillas de escape del shell con lspara generar una cadena entrecomillada conveniente para otros comandos. Utilicé este ejemplo de archivo extraño en otra respuesta más larga en otro lugar, pero también es relevante aquí:
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'