| View previous topic :: View next topic |
| Author |
Message |
Trevoke
Advocate
Joined: 04 Sep 2004
Posts: 4099
Location: NY, NY
|
 Posted: Mon Nov 14, 2005 1:54 pm Post subject: [SOFT : TCT] Recuperer des documents detruits |
 |
|
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 :
| Code: | # 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:
| Code: | | # 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)
| Code: | | $ 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:
| Code: | | $ 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:
| Code: | | $ 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 :
| Code: | | $ 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 !)
| Code: | | $ 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 -
| Code: | | $ 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!
______________________
** less : emerge most, je l'aime bien... 
[edit 1 : ajout d'accents et petites retouches, merci Blasserre!]
_________________
Votre moment detente
What is the nature of conflict?
Last edited by Trevoke on Tue Nov 15, 2005 2:51 pm; edited 1 time in total |
|
| Back to top |
|
 |
Enlight
Advocate
Joined: 28 Oct 2004
Posts: 3519
Location: Alsace (France)
|
| Posted: Tue Nov 15, 2005 10:34 am Post subject: |
|
|
| Blocs non alloués pour blocks non allocated. Merci pour ce How-to! |
|
| Back to top |
|
|
TGL
Bodhisattva
Joined: 02 Jun 2002
Posts: 1978
Location: Rennes, France
|
| Posted: Tue Nov 15, 2005 1:36 pm Post subject: |
|
|
| Yep, grand merci Trevoke. Avec un peu de chance ça servira pas trop souvent, mais si ça arrive, cette doc sera vraiment précieuse. |
|
| Back to top |
|
|
anigel
Bodhisattva
Joined: 14 Apr 2003
Posts: 1894
Location: Un petit bled pas loin de Limoges ;-)
|
| Posted: Tue Nov 15, 2005 2:38 pm Post subject: |
|
|
/agree,
Et... Merci Trevoke (plus particulièrement pour l'effort de mise en page, on se comprend  ) !
_________________
Il y a 10 sortes d'individus en ce bas-monde : ceux qui causent binaire, et les autres. |
|
| Back to top |
|
|
Trevoke
Advocate
Joined: 04 Sep 2004
Posts: 4099
Location: NY, NY
|
| Posted: Tue Nov 15, 2005 2:52 pm Post subject: |
|
|
Mais de rien, voyons!
D'ailleurs, pouf, une edition aujourd'hui, ajout d'accents -- merci Blasserre!
_________________
Votre moment detente
What is the nature of conflict? |
|
| Back to top |
|
|
blasserre
Veteran
Joined: 10 Feb 2004
Posts: 1362
Location: Lille, Vlaanderen
|
| Posted: Tue Nov 15, 2005 6:36 pm Post subject: |
|
|
you're welcome
dans la mesure où c'est moi qui ai fait remonter le post, fallait bien que je me fasse pardonner
_________________
benj
technicien professionnel, ascendant winner |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
French
