Pregunta ¿Hay archivos no recuperables en Linux?


Nunca había visto esto antes (20 años de * nix). He intentado guardar mi disco duro (detalles bajo pedido) y he tenido mucho éxito, excepto que hay algunos archivos que se ven así:

$ ls -al
$ ?????????? ?    ?       ?      ? blah.txt

Este archivo no se ve afectado por rm, rm -f, shred, mv, chown, chmod o cualquier otro comando que se me ocurra.

ejemplo

# whoami
root

# rm -f blah.txt
rm: cannot remove `blah.txt': permission denied

# ls -la blah.txt
?????????? ?    ?       ?      ? blah.txt

Básicamente lo mismo para cualquier comando en este archivo.

¿Algunas ideas?


4


origen


20 años de Unix y no has visto un sistema de archivos dañado o HD roto antes? Eres afortunado. - Janne Pikkarainen
Ah, eso es lo que pensé que podría ser. Sí, creo que he tenido suerte de esa manera. La HD no está rota, por cierto. Funciona bien. - bev
Eso generalmente significa que el nombre del archivo se encuentra en el directorio, pero no pudo acceder a su ínodo. Puede tener un número de inodo incorrecto en el directorio o puede haberse dañado el inodo en el disco. - mark4o


Respuestas:


¿Puede mostrarnos el resultado de 'lsattr blah.txt'? Eso nos indicará qué banderas especiales ha configurado este archivo.

También puede verificar en dmesg (el registro de mensajes de depuración del kernel) cualquier cosa nueva (ejecute dmesg dos veces, una vez antes de intentar eliminar un archivo, una vez después, y vea si aparece algo nuevo en la parte inferior del registro).

Un mensaje de ejemplo de corrupción del sistema de archivos puede verse así:

[86777.332361] EXT4-fs (dm-0): error count: 436
[86777.332365] EXT4-fs (dm-0): initial error at 1290174395: ext4_mb_generate_buddy:726
[86777.332367] EXT4-fs (dm-0): last error at 1292151653: ext4_mb_generate_buddy:726
[86777.332419] EXT4-fs (dm-8): error count: 1406
[86777.332423] EXT4-fs (dm-8): initial error at 1290623933: ext4_mb_generate_buddy:726
[86777.332425] EXT4-fs (dm-8): last error at 1292168399: ext4_mb_generate_buddy:726

e indica que ~ 86777 segundos desde el inicio (esta parte puede no mostrarse en su sistema, depende de la configuración del kernel) hubo dos errores relacionados con el sistema de archivos EXT4 en mi máquina de prueba.


1



@qdot, gracias por la sugerencia. No puedo probarlo porque algo que intenté eliminó el problema. He "tocado" el archivo (había abandonado la recuperación de datos) y ahora el archivo parece un archivo normal sin contenido. Mientras deambulo a través de mi fs, estoy seguro de que veré más de estos (2 hasta ahora), en ese momento intentaré lsattr y publicaré el resultado. - bev
@qdot - ok aquí está la salida: lsattr: Operación no soportada Mientras lee banderas en blah.txt. PERO, lsattr no devuelve ninguna información para ningún archivo en mi sistema. Dice: lsattr: ioctl inapropiado para el dispositivo Mientras lee indicadores en <cada archivo>. Entonces, lsattr no funciona en reiserfs o mi disco duro está dañado pero parece estar funcionando bien. Hmmmmm. Mirando dmesg ahora. - bev
ReiserFS: advertencia: is_tree_node: el nivel de nodo 0 no coincide con el esperado 1 ReiserFS: sda3: advertencia: vs-5150: search_by_key: formato no válido encontrado en el bloque 869576. Fsck? ReiserFS: sda3: advertencia: vs-13070: reiserfs_read_locked_inode: se produjo una falla de E / S al buscar datos estadísticos de [265071 265097 0x0 SD] ReiserFS: advertencia: is_tree_node: el nivel de nodo 0 no coincide con el esperado 1 ReiserFS: sda3: advertencia: vs-5150: search_by_key: formato no válido encontrado en el bloque 869576. Fsck? - bev
Yah. Parece que hay un problema con la estructura del inodo. Voy a ejecutar fsck de nuevo. - bev
Ran fsck - comprueba que ahora me dice que hay mucha corrupción y necesito ejecutar fsck --rebuild-tree. Entonces, habiendo copiado mi partición hace un par de días, ejecuté eso. Te llamaré sobre el resultado. - bev


Su sistema de archivos está dañado. Un fsck probablemente ayudaría.

edit: a menos que esté usando ReiserFS en cuyo caso fsck podría corromperlo más ...


7



Eso fue lo primero que hice. No devolvió ningún bloque malo. - bev
No puede ser otra cosa. Reconsidera esa posibilidad. Sin embargo, acabo de notar que estás usando ReiserFS. Tenga en cuenta que ReiserFS fsck podría destruir su sistema de archivos. Ese es uno de los defectos de diseño de ReiserFS ... - jlliagre
Uno de los defectos de diseño de reiserfs es que ejecutar reiserfsck podría destruir un sistema de archivos. Es bueno saberlo (después, por supuesto, ejecuté reiserfsck en mi sistema de archivos). Trataré de encontrar documentación sobre eso. Afortunado, hice una copia de seguridad de todo hace 2 días. Ah, y estabas en lo cierto. Volví a ejecutar fsck y me mostró muchos problemas. - bev
De en.wikipedia.org/wiki/ReiserFS: El proceso de reconstrucción de árbol de fsck de ReiserFS ha atraído muchas críticas: si el sistema de archivos se corrompe tanto que su árbol interno no se puede usar, realizar una operación de reconstrucción de árbol puede corromper aún más los archivos existentes o introducir nuevas entradas con contenido inesperado - jlliagre
@jlligre - gracias por el enlace. Bastante asustadizo. Estoy pensando en mi próximo movimiento. Tengo toda la partición respaldada. Tengo razones para creer que el HD físico está bien, la situación actual se debe a que me he metido con 2 HD externos después de que hice la copia de seguridad (aunque no veo lo que hice que causó esto). ¿Sugeriría que triture la partición y formatee con ext3? thx por el consejo. - bev


chattr +i file hace que un archivo esté completamente protegido contra escritura, incluso por root. Se llama inmutable. Para eliminar o modificar, primero debe volver a hacer que sea mutable chattr -i file.


4



gracias por la ayuda, desafortunadamente, no funcionó. Esto es lo que sucedió: $> chattr -i blah.txt $> chattr: Permiso denegado al intentar establecer la cuenta blah.txt - bev