Le fichier est mystérieusement vide. Options pour récupérer?

J'ai vu plusieurs articles sur la récupération de fichiers supprimés, mais cette situation est différente. Ma femme avait un fichier appelé Journal.odt dans lequel elle conservait beaucoup d'informations personnelles importantes telles que des souvenirs spéciaux sur nos enfants. L'autre jour, quand elle a essayé de l'ouvrir dans OpenOffice, elle s'est plainte du format. Je l'ai fait annuler et reculer. Lorsque je catle fichier, il est complètement vide. lsindique que le fichier fait 0 octet.

Si elle avait accidentellement sélectionné tout le texte du fichier, appuyé sur la touche de retour arrière et enregistré, il y aurait toujours les métadonnées OpenOffice dans le fichier.

J'ai immédiatement arrêté son ordinateur portable pour éviter de faire d'autres changements sur le disque jusqu'à ce que je puisse penser à quelque chose à faire.

J'ai fait des choses compliquées dans le passé, comme utiliser ddpour récupérer du texte brut sur le disque, mais je ne sais pas quoi faire ici. Étant donné que les fichiers odt ne sont pas du texte plat, je ne peux pas simplement diriger le disque entier via grep.

Toutes les suggestions seraient grandement appréciées.

Aussi, si quelqu'un a une idée de ce qui aurait pu mal tourner, j'aimerais l'entendre.

Merci

linux files data-recovery

— jcbwlkr
source

Ce serait différent si le fichier était accidentellement supprimé ou quelque chose, mais quand dans un éditeur de texte, etc., l'enregistrement du fichier écrit souvent "en place" en essuyant efficacement tout ce qui aurait pu être récupéré avec la récupération de la force médico-légale. Il aurait été préférable que vous ne fermiez pas le système immédiatement, je parie que quelques pressions sur control + z (fonction "annuler" intégrée dans Open Office) auraient corrigé le problème.

— Tim

@Tim Je vois votre point, mais malheureusement, le fichier avait été vidé quelques jours auparavant. La dernière modification de l'heure du fichier remonte à quelques jours. Dans ma description, quand elle l'a ouvert à OO, il était déjà vide. Merci quand même.

— jcbwlkr

Ne pas essayer de battre un cheval mort ou de donner un coup de pied à un homme lorsqu'il est à terre, mais je pense que cette expérience vous amènera à chercher une solution de sauvegarde. Jetez un œil à "Areca Backup" pour une application de sauvegarde simple et compatible Linux.

— Tim

Disque plein peut-être? Vérifiez avecdf -h

— jippie

@Tim Si le fichier fait 0 octet, ce n'est pas un document OO; Ctrl+Zn'aurait rien fait, car le fichier n'a pas été enregistré tel quel par OO. @ Jacobwalker0814 Les fichiers ODT sont des fichiers zip, donc les outils de récupération comme testdisk ont une chance de les trouver; mais il n'y a aucune garantie, et même si les données sont toujours là, vous devrez peut-être parcourir de nombreux autres fichiers zip. Et pour l'avenir, sauvegardez!

— Gilles 'SO- arrête d'être méchant'

Réponses:

Si vous utilisez le système de fichiers ext3, essayez de suivre le HOWTO de Carlo Wood

En quelques mots,

Utilisez ext3grep $ IMAGE --ls --inode 2 | grep votre_fichier pour trouver le fichier que vous recherchez (où $ IMAGE est votre partition par exemple / dev / sda2)
Recherchez le bloc de système de fichiers qui contient le journal de l'espace non alloué.
Recherchez tous les descripteurs de journal faisant référence au bloc qui ont été trouvés précédemment.
Copiez le bloc avec dd.
Modifiez le fichier pour supprimer les zéros de fin.
cat le fichier où tu veux

De la source:

"Le chapitre Exemple de récupération manuelle

Dans l'exemple suivant, nous allons récupérer manuellement un petit fichier. Seule une sortie partielle est donnée afin d'économiser de l'espace et de rendre l'exemple plus lisible.

En utilisant ext3grep $ IMAGE --ls --inode, nous trouvons le nom du fichier que nous voulons récupérer:

$ ext3grep $ IMAGE --ls --inode 2 | grep carlo 3 end d 195457 D 1202352103 jeu 7 fév 03:41:43 2008 drwxr-xr-x carlo

$ ext3grep $ IMAGE --ls --inode 195457 | grep 'bin $' | tête -n 1 34 35 d 309540 D 1202352104 jeu 7 fév 03:41:44 2008 drwxr-xr-x bin

$ ext3grep $ IMAGE --ls --inode 309540 | grep start_azureus 9 10 r 309631 D 1202351093 jeu 7 fév 03:24:53 2008 rrwxr-xr-x start_azureus

De toute évidence, l'inode 309631 est effacé et nous n'avons aucun numéro de bloc pour ce fichier:

$ ext3grep $ IMAGE --print --inode 309631 [...] L'inode est un groupe non alloué: 19 Génération ID: 2771183319 uid / gid: 1000/1000 mode: rrwxr-xr-x taille: 0 nombre de liens: 0 secteurs: 0 (-> 0 blocs indirects).

Inode Times: Accessed: 1202350961 = Thu Feb 7 03:22:41 2008 File Modified: 1202351093 = Thu Feb 7 03:24:53 2008 Inode Modified: 1202351093 = Thu Feb 7 03:24:53 2008 Heure de suppression: 1202351093 = Thu 7 févr 03:24:53 2008

Blocs directs:

Par conséquent, nous essaierons d'en rechercher une copie plus ancienne dans le journal. Tout d'abord, nous trouvons le bloc de système de fichiers qui contient cet inode:

$ ext3grep $ IMAGE --inode-to-block 309631 | grep réside L'inode 309631 réside dans le bloc 622598 à l'offset 0xf00.

Ensuite, nous trouvons tous les descripteurs de journal référençant le bloc 622598:

$ ext3grep $ IMAGE --journal --block 622598 [...] Descripteurs de journal faisant référence au bloc 622598: 4381294 26582 4381311 28693 4381313 28809 4381314 28814 4381321 29308 4381348 30676 4381349 30986 4381350 31299 4381374 32718 438 438 438 438 438 438 4382137 6672 4382138 7536 4382139 7984 4382140 8931

Cela signifie que la transaction avec le numéro de séquence 4381294 a une copie du bloc 622598 dans le bloc 26582, etc. Le plus grand numéro de séquence, en bas, doit être les dernières données écrites sur le disque et donc le bloc 8931 doit être le même que le bloc actuel 622598. Pour trouver la dernière copie non supprimée, il faut commencer par le bas et travailler vers le haut.

Si vous essayez d'imprimer un tel bloc, ext3grep reconnaît qu'il s'agit d'un bloc d'une table d'inodes et imprimera le contenu des 32 inodes qu'il contient. Nous souhaitons seulement voir l'inode 309631 cependant; nous utilisons donc un grep intelligent:

$ ext3grep $ IMAGE --print --block 8931 | grep -A15 'Inode 309631' -------------- Inode 309631 ----------------------- ID de génération: 2771183319 uid / gid: 1000/1000 mode: rrwxr-xr-x taille: 0 nombre de liens: 0 secteurs: 0 (-> 0 blocs indirects).

Inode Times: Accessed: 1202350961 = Thu Feb 7 03:22:41 2008 File Modified: 1202351093 = Thu Feb 7 03:24:53 2008 Inode Modified: 1202351093 = Thu Feb 7 03:24:53 2008 Heure de suppression: 1202351093 = Thu 7 févr 03:24:53 2008

Blocs directs:

C'est en effet le même que celui que nous avons vu dans le bloc 622598. Ensuite, nous regardons les numéros de séquence plus petits jusqu'à ce que nous en trouvions un avec un temps de suppression de 0. Le premier que nous trouvons (de bas en haut) est le bloc 6073:

$ ext3grep $ IMAGE --print --block 6073 | grep -A15 'Inode 309631' -------------- Inode 309631 ----------------------- ID de génération: 2771183319 uid / gid: 1000/1000 mode: rrwxr-xr-x taille: 40 nombre de liens: 1 secteurs: 8 (-> 0 blocs indirects).

Inode Times: Accessed: 1202350961 = Thu Feb 7 03:22:41 2008 File Modified: 1189688692 = Thu Sep 13 15:04:52 2007 Inode Modified: 1189688692 = Thu Sep 13 15:04:52 2007 Temps de suppression: 0

Blocs directs: 645627

Ce qui précède est automatisé et peut être fait beaucoup plus rapidement avec l'option de ligne de commande --show-journal-inodes. Cette option trouvera le bloc auquel appartient l'inode, puis trouvera toutes les copies de ce bloc dans le journal, et imprime ensuite uniquement l'inode demandé de chacun de ces blocs (chacun contenant 32 inodes, comme vous le savez), éliminant les doublons :

$ ext3grep $ IMAGE --show-journal-inodes 309631 Nombre de groupes: 75 Bloc de journal minimum / maximum: 1115/35026 Chargement des descripteurs de journal ... terminé La transaction de journal 4381435 se termine, certains blocs de données peuvent avoir été perdus de cette transaction. Nombre de descripteurs dans la revue: 30258; numéros de séquence min / max: 4379495/4382264 Copies de l'inode 309631 trouvées dans le journal:

-------------- Inode 309631 ----------------------- ID de génération: 2771183319 uid / gid: 1000/1000 mode: rrwxr-xr-x taille: 0 nombre de liens: 0 secteurs: 0 (-> 0 blocs indirects).

Inode Times: Accessed: 1202350961 = Thu Feb 7 03:22:41 2008 File Modified: 1202351093 = Thu Feb 7 03:24:53 2008 Inode Modified: 1202351093 = Thu Feb 7 03:24:53 2008 Heure de suppression: 1202351093 = Thu 7 févr 03:24:53 2008

Blocs directs:

-------------- Inode 309631 ----------------------- ID de génération: 2771183319 uid / gid: 1000/1000 mode: rrwxr-xr-x taille: 40 nombre de liens: 1 secteurs: 8 (-> 0 blocs indirects).

Inode Times: Accessed: 1202350961 = Thu Feb 7 03:22:41 2008 File Modified: 1189688692 = Thu Sep 13 15:04:52 2007 Inode Modified: 1189688692 = Thu Sep 13 15:04:52 2007 Temps de suppression: 0

Blocs directs: 645627

Le fichier est en effet petit: un seul bloc. Nous copions ce bloc avec dd comme indiqué précédemment:

$ dd if = $ IMAGE bs = 4096 count = 1 skip = 645627 of = block.645627 1 + 0 enregistrements en 1 + 0 enregistrements out 4096 octets (4,1 kB) copiés, 0,0166104 secondes, 247 kB / s

puis éditez le fichier pour supprimer les zéros de fin, ou copiez les 40 premiers octets (la taille donnée du fichier):

$ dd if = block.645627 bs = 1 count = 40 of = start_azureus 40 + 0 enregistrements in 40 + 0 enregistrements out 40 octets (40 B) copiés, 0,000105397 secondes, 380 kB / s

$ cat start_azureus cd / usr / src / azureus / azureus ./azureus &

Rétabli!"

— java_xof
source

J'aimerais voir ça, mais le lien semble mort.

— jcbwlkr

Ça ne me semble pas mort.

— M. Lister

oui, je peux y accéder non plus.

— java_xof

Ça fonctionne bien maintenant. Ce n'était définitivement pas plus tôt. Qui sait? Merci, java. Je vais le regarder.

— jcbwlkr

Pas de problème, j'espère que cette aide vous, aucune infraction mais je sais quelque chose sur l'interaction femme <-> ordinateur;)

— java_xof

Essayez testdisk et photorec , mais la façon dont je comprends votre écriture est probablement la manière la plus difficile d'apprendre la valeur des sauvegardes régulières. Vous pouvez également vouloir démarrer à partir du CD pour éviter que le disque dur ne soit encore modifié. Personnellement, j'aime System Rescue Disk pour cela, mais il est largement basé sur la ligne de commande.

— jippie
source

Utilisez Caine une distribution Linux spéciale pour la criminalistique numérique. C'est beaucoup d'outils pour la récupération de fichiers et de disques durs.

— PsyStyle
source

Merci. Je vais regarder cette distribution et voir si elle a quelque chose. Avez-vous des recommandations sur des outils spécifiques ou des façons d'aborder le problème? Le problème ici est que le fichier n'a pas été supprimé, ce que de nombreux outils semblent résoudre; il vient de perdre son contenu.

— jcbwlkr

Open Office crée parfois un fichier caché qui contient le document enregistré précédent. Si vous êtes chanceux, vous pouvez essayer de le récupérer en utilisant par exemple "extundelete" ou "testdisk" cgsecurity.org/wiki/TestDisk

— PsyStyle

Regardez dans ~ / .openoffice.org / 3 / user / backup / ou ~ / .libreoffice.org / 3 / user / backup / J'ai écrit un script pour effacer ces répertoires afin que les éléments sensibles que j'ai supprimés ne soient pas encore là.

— Joe