Lea el final del archivo pasado para recuperar datos

Un archivo .swp muy antiguo revirtió un archivo que estaba editando, por lo que ahora es significativamente más corto. Desde entonces no he hecho nada en ese directorio, por lo que los bytes que siguen inmediatamente al final del archivo aún deberían tener mis datos. ¿Qué función puedo usar para leer N bytes de una dirección de memoria dada? ddy readdetenerse en los límites del archivo, a menos que haya perdido una opción en alguna parte.

El tamaño actual del archivo es de 3.2 KB. No recuerdo exactamente qué tan grande era el archivo antes de que se truncara, pero probablemente no más de 10 KB. ¿Cómo puedo leer 10 KB desde el principio del archivo, ignorando los límites del archivo? Está bien si los datos no se conservan perfectamente, siempre que no tenga que comenzar desde cero.

data-recovery

— Matthew Bedford
fuente

Por lo general, cuando los editores guardan archivos, eliminan o truncan a 0, liberando así el espacio asignado y luego escriben, lo que asigna nuevo espacio. Esto da como resultado que el sistema de archivos coloque los datos en una ubicación física completamente diferente. Entonces su idea podría no funcionar.

Puede obtener la ubicación física de un archivo usando filefrago hdparm --fibmap, y luego usar ddpara leer esa ubicación física directamente. Aquí describí este proceso en un contexto diferente: /unix//a/85880/30851

En su caso, es más probable que necesite el enfoque general para encontrar datos textuales ... algo como:

strings -n 12 -t d /dev/partition | grep -F 'text snippet'

strings buscará datos ASCII consecutivos (también admite algunas otras codificaciones, no estoy seguro acerca de UTF-8. Si es código o inglés, no lo necesitará) y también imprimirá el desplazamiento donde se encontró.

text snippetdebe ser una muestra de texto exacta y única que recuerde que estaba en la parte del archivo que está buscando [en una sola línea]. (Si no lo sabe exactamente, puede utilizar expresiones regulares).

-n 12es la longitud mínima que stringsbuscará. 12debe ser la longitud de tu text snippet. Este parámetro es opcional, si se proporciona, podría ayudar strings | grepir un poco más rápido.

Le tomará mucho tiempo leer la partición completa, pero si tiene éxito, tendrá un desplazamiento que puede alimentar ddpara tomar el área general y luego eliminar cosas que no pertenecen.

No he hecho nada en ese directorio desde

Si su directorio no es un punto de montaje ... la mayoría de los sistemas de archivos realmente no reservan espacio "por directorio", así que ... todas y cada una de las escrituras en todo el sistema de archivos podrían sobrescribir el bit que está buscando. En una situación de recuperación de datos, generalmente cambia todo en modo de solo lectura.

— Frostschutz
fuente

Tenga en cuenta que cada archivo se almacena en muchos bloques y, por lo general, no se almacenan consecutivamente. Por stringslo tanto , solo localizará algunas partes del archivo a menos que tenga mucha suerte.

— Gilles 'SO- deja de ser malvado'

Todo lo contrario, tendría que ser extremadamente desafortunado para encontrar un archivo fragmentado de 10 KB. Si solo encuentra una parte, es más probable que la otra parte se haya sobrescrito en este caso. Pero a menos que tenga mucha actividad de escritura en ese sistema de archivos, o sea un SSD con descarte instantáneo, si guardó ese archivo varias veces durante la edición, puede encontrar muchas copias de ese archivo.

— frostschutz

Recomendaría strings -n16o una longitud mínima razonable, para que sea más rápido.

— Peter Cordes

Buen punto, lo agregó a la respuesta.

— frostschutz

Gracias un montón. Solo había basura justo después del final del archivo, pero stringspude encontrar el archivo completo en otra parte de la partición. Son casi dos meses de trabajo que no tengo que volver a hacer, y un excelente recordatorio para usar siempre el control de versiones para cualquier cosa importante.

— Matthew Bedford el