# [SOFT : TCT] Recuperer des documents detruits

## Trevoke

Ceci est une traduction du mode d'emploi pour récupérer un fichier avec tct (emerge tct).

Toute la documentation pour tct est, à l'heure ou j'écris ces lignes, dans /usr/share/doc/tct-1.15-r1, donc c'est là qu'il faut aller voir pour de plus amples informations!

Tout d'abord, voici une liste de problèmes:

 Tu n'as pas accès a root

 Tu ne connais rien à Unix

 Tu es pressé

 Le fichier est plus gros que 15-20 ko

Ensuite, il te faut:

Une connaissance de base de ton système

 De l'espace libre sur un disque dur (ET SURTOUT PAS SUR LA PARTITION OÙ TU AS PERDU LES FICHIERS). Environ 220% de la place libre sur cette partition, d'ailleurs. 

 Au moins quelques heures de temps libre

En gros, tu vas lancer unrm pour récupérer les données d'un système de fichiers et les sauver sur un autre. Ensuite tu lances lazarus et ensuite tu passes les résultats au peigne fin.

#1 sur quel système de fichiers on est?.. Mais c'est ou sur ton disque, aussi? quelle partition? Ça, c'est pour trouver combien de place libre il y a dessus, comme ça tu peux chercher une autre partition avec la place dont tu as besoin. (df -h)

#2 sauver les blocs non-alloués du système de fichiers. Encore une fois, N'UTILISE PAS LA MÊME PARTITION!

Alors, admettons que tu aies /dev/sda1 (où tu as perdu le fichier) et /dev/sda2 (qui a, bien sûr, environ 2,5 fois plus d'espace libre que /dev/sda1). Il faut

a) décider où sur /dev/sda2 tu vas sauvegarder les données. Admettons que ce soit sur /path/to/TCT

b) taper : 

```
# cd /path/to/TCT

# unrm /dev/sda1 > /path/to/TCT/unrm_output
```

Maintenant on attend.

Voila, si le fichier est encore sur le disque, il est maintenant quelque part dans /path/to/TCT/unrm_output

Maintenant si tu t'y connais tu peux parser le binaire, mais continuons..

#3 Lance lazarus sur le résultat. En général ça sera comme ça:

```
# lazarus -h unrm_output
```

-h --> crée de l'HTML qu'on peut donc voir avec un fichier.

#4 maintenant c'est compliqué. Il y a deux méthodes à suivre. Si tu connais quelques mots ou un mot rare du fichier, ou si le fichier est un peu spécial, utilise la méthode A, sinon, utilise la méthode B.

MÉTHODE A

Si tu as des images, remarque, c'est simple, tu peux faire comme ça (remplace 'xv' par ton éditeur d'images:

(en supposant que tu es dans le répertoire où il y a unrm_output)

```
$ xv blocks/*.gif blocks/*.jpg
```

Admettons que tu cherches un fichier qui a le mot "Studebaker" dedans. C'est assez sympa, parce que c'est rare, donc les chances que plusieurs fichiers aient ce mot sont assez restreintes...

Donc, tu utilises ton meilleur copain, grep sur les blocs qui ont ete sauvegardés:

```
$  grep -il studebaker blocks/* > matching_files
```

--> -i ignore les majuscules/minuscules, et -l liste les noms de fichiers.

Si vous voyez un résultat, examinez le(s) fichier)s listé(s) avec un bon pager comme less **. Si vous trouvez, bravo!

La méthode indiquée au-dessus peut échouer avec une erreur comme "Argument list too long" quand il y a trop de fichiers. Dans cette situation, utilisez la commande ci-dessous, plus robuste mais un peu plus longue à taper:

```
$ find blocks -type f -print | xargs grep -il studebaker >matching_files
```

Si vous cherchez quelque chose de moins unique, pensez à des mots clés qui peuvent vous aider (comme votre nom, votre employeur, etc etc). Vous pouvez écrire quelque chose comme ceci : 

```
$ egrep -il 'keyword1|keyword2|...' blocks/*.txt > matching_files
```

Les fichiers log (syslog, message, etc), même s'ils sont souvent éparpillés sur tout le disque à cause de la façon dont ils sont écrits (quelques lignes à la fois), sont en fait, potentiellement, simples à récuperer - et dans le bon ordre - grâce au merveilleux time stamp sur chaque ligne. La solution la plus simple (jusqu'à ce qu'un meilleur analyseur de logs soit écrit) est de faire ceci : (le tr est dedans pour retirer les NULL; les commandes comme sort n'aiment pas les NULLs dans les fichiers avec lesquels elle travaillent !)

```
$ cat blocks/*.l.txt | tr -d '\000' | sort -u > all-logs
```

Et ensuite, y a plus qu'à vérifier. Des petits morceaux seront probablement perdus (à cause de la fragmentation), mais c'est un bon début.

Il est très facile de mélanger certaines données, comme le code C, avec d'autres programmes et du texte, donc un mélange de la méthode grep & le browser est parfois utile (un peu plus sur le browser dans la méthode B).

Une autre bonne façon de trouver du code source: si tu connais un fichier #include spécifique que le code utilise, ou une ligne d'output spécifique que le programme sort - 

```
$ grep -l rpcsvc/sm_inter.h blocks/*.[cpt].txt
```

Ceci touvera tous les fichiers qui ont rpcsvc/sm_inter.h dedans (probablement pas des masses!). Ce genre de méthode de force brute peut être très utile.

ATTENTION à ne pas concaténer trop de fichier/blocs récuperés ensemble et à faire des recherches ou des opérations basées sur le texte (sort, grep, uniq, etc), parce que les utilitaires de texte se mélangent souvent les pédales (ou pire) quand ils rencontrent du binaire, qui est souvent dans l'output de lazarus.

MÉTHODE B

Utiliser un browser, c'est beaucoup plus joli, mais c'est pas vraiment fantastique quand tu cherches juste ce petit fichier que tu as perdu. Cependant, un browser peut être le bienvenu quand on cherche des fichiers intéressants en général... Pour lancer le browser, il y a juste à ouvrir le fichier HTML généré avec lazarus - il aura un nom comme unrm_output.frame.html si les données originales s'appelaient unrm_output.

Si ça a été fait correctement, vous verrez une grande carte de votre disque faite de lettres, et une frame HTML qui vous montre ce que toutes les lettres de la carte signifient. Vous pouvez utiliser la fonction de recherche interne au browser, ou juste passer à travers manuellement en cherchant ce qui vous intéresse. Cliquer sur un lien montrera les données dans ce fichier (à moins que ce ne soit des données unprintable).

Certaines données, comme le code C, sont dûres à distinguer pour lazarus, comme indiqué au-dessus. Par exemple, si vous avez une section de données qui ressemble à cela sur la carte : 

      ....CccPpC..Hh....

Les trois premiers types de texte reconnus - C, P, C - peuvent tous être le même genre de texte (C). Trouver le numéro de bloc en passant sa souris au-dessus du lien et ensuite concaténer les fichiers ensemble, ou les examiner à la main, marche très bien.

Cette approche peut être très utile si tu as beaucoup de fichiers sur le disque. Parce que les systèmes de fichiers UNIX ont souvent un grand sens de localité qui est lié aux répertoires dans lesquels les fichiers étaient, tu peux utiliser le browser pour trouver la location d'une section du disque qui a l'air intéressante, et commencer la chasse avec le browser ou avec les utilitaires UNIX standards sur les blocs sauvegardés.

Comme tu peux voir, si tu as lu jusqu'ici, c'est très, *très* loin d'être un procédé automatique. Cependant, il est vraiment possible de récupérer des fichiers. Dans le futur, le processus deviendra peut-etre moins ardu, c'est-à-dire si les créateurs implémentent les utilitaires auxquels ils pensent (chercher à partir du browser, montrer les données même si on ne peut pas les imprimer, etc) ou si d'autres travaillent sur ce problème important.

BONNE CHANCE!

----------

## Enlight

Blocs non alloués pour blocks non allocated. Merci pour ce How-to!

----------

## TGL

Yep, grand merci Trevoke. Avec un peu de chance ça servira pas trop souvent, mais si ça arrive, cette doc sera vraiment précieuse.

----------

## anigel

/agree,

Et... Merci Trevoke (plus particulièrement pour l'effort de mise en page, on se comprend  :Wink:  ) !

----------

## Trevoke

Mais de rien, voyons!

D'ailleurs, pouf, une edition aujourd'hui, ajout d'accents -- merci Blasserre!  :Smile: 

----------

## blasserre

you're welcome

dans la mesure où c'est moi qui ai fait remonter le post, fallait bien que je me fasse pardonner  :Wink: 

----------

