Hice un archivo por accidente con un nombre de archivo de (NUL).xml , excepto que en lugar de (NUL) Es literalmente '\0' . Ninguno de los métodos que he probado ha funcionado para eliminarlo realmente. ¿Hay alguna forma de eliminar el archivo mediante una referencia alternativa?
De acuerdo, no puedo probar esto (por razones que espero sean obvias), pero cuando los nombres de los archivos son tu problema... usa inode ¡s!
Primero, en un directorio, ejecute ls -il (-i es mostrar números de nodo y -l es para convertirlo en una lista):
2480878 -rw-r--r-- 1 christopher family 0 Mar 2 19:40 *a
2480889 -rw-r--r-- 1 christopher family 0 Mar 2 19:40 \\a
2480873 -rw-r--r-- 1 christopher family 0 Mar 2 19:39 aEn este ejemplo, voy a borrar el archivo \\a que es el inodo 2480889 .
Así que corro find . -inum 2480889 -delete .
Esperemos que esto funcione.
AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.
0 votos
Lo creé con una versión antigua de Java que me permitía crear archivos con un byte nulo en el nombre del archivo por accidente. Por desgracia, hace tiempo que actualicé y clri no está disponible en El Capitán, así que ni siquiera puedo borrar el inodo.
0 votos
He probado eso y mucho más. No funciona.
0 votos
Más o menos espero que alguien tenga un método para limpiar los inodos en El Capitán.
0 votos
El problema con eso es que intenta eliminar el archivo usando el nombre del archivo, que es exactamente el problema. El byte nulo está haciendo tropezar a rm.
0 votos
Sí. Eso se encuentra con el mismo problema, ya que invoca la llamada unlink() contra el nombre del archivo.
0 votos
Lo he probado con
clri /dev/disk0s2 -inode(de una instalación 10.6 copiada a un sistema 10.9) y manipulando directamente el archivo de catálogo con un editor hexadecimal. Nada funciona o corrompe completamente el disco (esto último).0 votos
Por "corrompe completamente el disco", ¿quieres decir que requiere fsck? Porque ese es un comportamiento conocido y esperado con clri.
0 votos
Clri no funciona con el siguiente mensaje (¿error?):
clri: /dev/disk0s2: superblock magic number 0x0, not 0x11954. Manipular directamente el archivo de catálogo del sistema de archivos con un editor hexadecimal corrompe completamente el volumen y no se puede recuperar aunque sólo haya cambiado 4 bytes.0 votos
¿Es el único archivo de un directorio? ¿O es el único archivo con una determinada extensión? Entonces puede intentar utilizar
rmcon un comodín en lugar del carácter ofensivo o eliminar todo el directorio (rm -rf ./THEDIRECTORY)? O bien, podría buscar en unix.stackexchange.com/questions/28983/ que también podría ayudar. Suelo buscar respuestas de linux en estos casos. Otra solución: instalar midnight commander - que suele funcionar en estos casos.