
                      Linux Ext2fs Undeletion mini-HOWTO

Aaron Crane, aaronc@pobox.com

   v1.3, 2 Fvrier 1999
     _________________________________________________________________

   _(Adaptation franaise par Miodrag Vallat, anciennement par Graud
   Canet et Sylviane Regnault). Imaginez un peu. Vous avez pass les
   trois derniers jours sans dormir, sans manger, sans mme prendre une
   douche. Votre bidouillomanie compulsive a enfin port ses fruits :
   vous avez achev ce programme qui vous apportera gloire et admiration
   du monde entier. Allez, plus qu' archiver tout a et l'envoyer 
   Metalab. Ah, et puis virer toutes ces sauvegardes automatiques
   d'Emacs. Alors vous tapez rm * ~. Et, trop tard, vous remarquez
   l'espace en trop. Vous avez dtruit votre oeuvre matresse ! Mais,
   heureusement, vous avez de l'aide  porte de main. Ce document
   prsente une discussion de la rcupration de fichiers supprims
   depuis le Second systme de fichiers tendu ext2fs. Esprez, peut-tre
   pourrez-vous distribuer votre programme malgr tout..._
     _________________________________________________________________

1. Introduction

   Ce mini-HOWTO tente de fournir un certain nombre de conseils dans le
   but de rcuprer des fichiers supprims depuis un systme de fichiers
   ext2fs. Il contient galement une petite discussion sur les manires
   de commencer par viter de supprimer des fichiers.

   Mon but est naturellement d'en faire une rfrence utile  tous ceux
   qui ont eu un, disons... accident avec rm ; mais cependant je souhaite
   que les gens le lisent de toute faon. On ne sait jamais : un jour,
   les renseignements donns ici pourraient vous sauver la couenne.

   La lecture de ce texte suppose un minimum de connaissances sur les
   systmes de fichiers Unix ; je me suis cependant efforc de le rendre
   accessible  la plupart des utilisateurs de Linux. Si vous tes un
   grand dbutant, je crains que la rcupration de fichiers sous Linux
   _exige_ certaines connaissances techniques, ainsi que de la
   persvrance, au moins dans l'tat actuel des choses.

   Il vous sera impossible de rcuprer des fichiers supprims depuis un
   systme de fichiers ext2 sans au moins un accs en lecture au
   priphrique (fichier spcial) sur lequel le fichier tait plac. En
   gnral, cela signifie que vous devez tre _root_, mais plusieurs
   distributions (comme Debian GNU/Linux) disposent d'un groupe disk dont
   les membres ont ces accs. Vous aurez galement besoin de la commande
   debugfs, du paquetage e2fsprogs, qui devrait avoir t install par
   votre distribution.

   Pourquoi ai-je crit ceci ? Principalement par exprience personnelle,
   souvenir du dsastre d'un rm -r particulirement insens en tant que
   _root_. J'ai supprim 97 fichiers JPEG dont j'avais besoin et que je ne
   pouvais certainement pas rcuprer par ailleurs. Suivant quelques
   conseils (voir la section Remerciements et bibliographie) et en
   persvrant beaucoup, j'ai rcupr 91 fichiers intacts. Je suis
   parvenu  en retrouver, au moins en partie, cinq autres (suffisamment
   pour voir quelle tait l'image reprsente par chacun). Une seule
   n'tait pas affichable, et mme pour celle-l, je suis certain de
   n'avoir pas perdu plus de 1024 octets (mais hlas depuis le dbut du
   fichier ; sachant que je ne connais rien du format de fichier JFIF
   j'ai vraiment fait ce que j'ai pu).

   Je discuterai plus bas du taux de rcupration que vous pouvez esprer
   pour les fichiers supprims.

1.1 Historique des rvisions

   Les rvisions de ce document (en version anglaise, NdT) dlivres au
   public, ainsi que leurs dates de publication, sont les suivantes :

     * v1.0, 18 janvier 1997 ;
     * v1.1, 23 juillet 1997 (voir Nouveauts v1.1) ;
     * v1.2, 4 aot 1997 (voir Nouveauts v1.2) ;
     * v1.3, 2 fvrier 1999 (voir Nouveauts v1.3).

  Nouveauts de la version 1.1

   Quels sont les nouveauts de cette version ? Primo, la rflexion dans
   l'exemple de la rcupration de fichiers a t corrige. Merci  tous
   ceux qui m'ont crit pour me signaler mon erreur ; cela m'apprendra,
   je l'espre,  faire plus attention en inventant des squences
   interactives.

   Secundo, la discussion sur le modle de systme de fichier Unix a t
   rcrite afin d'tre (esprons-le) plus comprhensible. Je n'en tais
   pas entirement satisfait de prime abord, et d'aucuns se sont plaints
   de son manque de clart.

   Tertio, le gros-tas-de-tar-gzip-uu-encod de fsgrab au milieu du
   fichier a t retir. Le programme est dsormais disponible sur ma
   page et sur Metalab (et ses miroirs).

   Quarto, le document a t traduit en langage sgml, utilis par le
   Linux Documentation Project. Ce langage peut tre facilement converti
   en un grand nombre d'autres langages (y compris HTML et LaTeX) pour un
   affichage et une impression simples et pratiques. Cela a pour avantage
   une belle typographie, dans le cas d'une dition papier ; de plus, le
   document contient des rfrences et des liens bien commodes si vous le
   consultez sur le Web.

  Nouveauts de la version 1.2

   Cette rvision est plutt une augmentation. Elle inclut principalement
   des modifications proposes par des lecteurs, dont l'une est
   particulirement importante.

   Le premier changement a t suggr par Egil Kvaleberg
   egil@kvaleberg.no, qui a signal la commande dump dans debugfs. Merci
   encore, Egil.

   Le second changement a t de signaler l'utilisation de chattr pour
   viter de supprimer des fichiers importants. Merci  Herman Suijs
   H.P.M.Suijs@kub.nl de l'avoir signal.

   Le rsum a t revu. Des URLs ont t ajoutes, qui indiquent des
   organisations ou des logiciels. Ajoutez  cela quelques modifications
   mineures (dont des corrections de fautes de frappe, etc.).

  Nouveauts de la version 1.3

   Bien qu'il se soit coul 17 mois depuis la dernire version, bien peu
   de choses ont chang. Cette version corrige quelques erreurs mineures
   (fautes de frappe, URL incorrectes, etc -- principalement le non-lien
   vers l'Open Group), et les quelques paragraphes qui taient devenus
   atrocement dmods, comme ceux sur les versions de noyau et lde, ont
   t revus. Oh, et j'ai remplac `Sunsite' par `Metalab' partout.

   Cette version sera probablement la dernire avant la version 2.0, qui
   sera un vrai HOWTO, du moins je l'espre. J'ai travaill sur des
   changements d'importance qui mritent l'incrmentation du numro de
   version majeure.

1.2 O trouver ce document

   La version officielle la plus rcente de ce document devrait tre
   disponible au format texte auprs du site du Linux Documentation
   Project (et ses miroirs). La dernire version est galement disponible
   sur ma page sous divers formats :

     * source SGML, tel que je l'ai crit ;
     * HTML, gnr automatiquement depuis le source SGML ;
     * format texte, galement gnr automatiquement depuis le source
       SGML.

2. Comment ne pas supprimer de fichiers

   Il est vital de se rappeler que Linux n'est pas semblable  MS-DOS en
   matire de rcupration de donnes. Pour MS-DOS (et son btard Windows
   95), il est gnralement trs simple de rcuprer un fichier
   supprim : le  systme d'exploitation  (il faut le dire vite) est
   mme accompagn d'un utilitaire qui automatise la procdure. Ce n'est
   pas le cas de Linux.

   Donc... rgle numro un (ou premire directive, si vous prfrez) :

     _FAITES DES SAUVEGARDES_

   peu importe comment. Pensez  toutes vos donnes. Peut-tre, comme
   moi, conservez-vous plusieurs annes d'archives de messages, contacts,
   documents sur votre ordinateur. Pensez au chamboulement dans votre vie
   si vous tiez victime d'une panne de disque catastrophique, ou -- pire
   encore ! -- si un cracker nettoyait votre disque sans vergogne. Ce
   n'est pas si improbable ; j'ai correspondu avec un bon nombre de gens
   placs dans une telle situation. J'exhorte les utilisateurs senss de
   Linux de sortir acheter un priphrique de sauvegarde, de planifier
   leurs sauvegardes dans un emploi du temps digne de ce nom et de _s'y
   conformer_. En ce qui me concerne, je me sers d'un disque ddi sur
   une deuxime machine, et rgulirement je fais un mirroir de mon
   rpertoire personnel par le rseau. Pour plus d'information sur la
   planification des sauvegardes, lisez Frisch (1995) (voir la section
   Bibliographie et remerciements).

   En l'absence de sauvegardes, que faire (en fait, mme en prsence de
   sauvegardes : dans le cas de donnes importantes, la ceinture et les
   bretelles, ce n'est pas du luxe) ?

   Essayez de donner aux fichiers importants les droits 440 (ou moins) :
   ne pas vous laisser les droits en criture provoque une demande de
   confirmation explicite de rm avant la destruction (mais si je veux
   supprimer rcursivement un rpertoire avec rm -r, j'interromprai le
   programme ds la premire ou deuxime demande de confirmation pour
   relancer la commande avec rm -rf).

   Un bon truc, pour les fichiers importants, est de crer un lien
   physique vers eux dans un rpertoire cach. J'ai entendu parler d'un
   administrateur systme qui, priodiquement, supprimait
   accidentellement /etc/passwd (et par l-mme dtruisait  moiti le
   systme). Un des remdes fut de lancer en tant que _root_ quelque
   chose comme :

# mkdir /.backup
# ln /etc/passwd /.backup

   Il est alors assez difficile de supprimer compltement le contenu du
   fichier : si vous dites

# rm /etc/passwd

   alors

# ln /.backup/passwd /etc

   permettra de le rcuprer. Naturellement, cela ne couvre pas le cas o
   vous avez cras le contenu du fichier par un autre fichier, donc de
   toutes faons gardez vos sauvegardes.

   Dans un systme de fichiers ext2, il et possible d'utiliser les
   attributs ext2 dans le but de protger ses donnes. Ces attributs sont
   manipuls  l'aide de la commande chattr. Il y a un attribut  ajout
   seulement  (_append-only_) : il est possible d'ajouter des donnes 
   un fichier ayant cet attribut, mais pas de le supprimer, et le contenu
   du fichier ne peut pas tre cras. Si un rpertoire a cet attribut,
   tous les fichiers et rpertoires qu'il contient peuvent tre
   normalement modifis, mais aucun fichier ne peut tre supprim. Cet
   attribut peut tre plac en tapant

$ chattr +a FICHIER...

   Il existe aussi un attribut  immuable  (_immutable_), qui ne peut
   tre plac ou retir qu'en tant que _root_. Un fichier ou rpertoire
   ayant cet attribut ne peut tre ni modifi, ni supprim, ni renomm,
   ni se faire ajouter un lien (physique). Il peut tre plac comme
   suit :

# chattr +i FICHIER...

   Ext2fs fournit galement l'attribut  rcuprable  (_undeletable_,
   option +u de chattr). Si un fichier ayant cet attribut est supprim,
   mais pas rellemnt rutilis, il est dplac vers un  endroit sr 
   afin d'tre supprim plus tard. Hlas, cette fonctionnalit n'est pas
   encore implante dans les noyaux courants ; et bien que, par la pass,
   il y ait eu un peu d'intrt concernant une implantation ventuelle,
   elle n'est pas ( ma connaissance) disponible pour les noyaux actuels.

   Certains dfendent l'ide de faire de rm un alias ou une fonction du
   gestionnaire de commandes qui excute en fait rm -i (qui demande
   confirmation pour _tous_ les fichiers  supprimer). En effet,
   certaines versions de la distribution Red Hat le font par dfaut pour
   tous les utilisateurs, y compris _root_. En ce qui me concerne, je ne
   supporte pas les logiciels incapables de tourner tous seuls, je ne le
   fais donc pas. Par ailleurs, un jour ou l'autre, vous ferez tourner le
   programme en mode mono-utilisateur, ou utiliserez un gestionnaire de
   commandes diffrent, ou simplement une autre machine, o votre
   fonction rm n'existera pas. Si vous vous attendez  une confirmation,
   il est assez facile d'oublier o vous tes et spcifier un peu trop de
   fichiers  supprimer. De mme, les divers scripts et programmes
   servant  remplacer rm sont,  mon humble avis, trs dangereux.

   Une solution un peu meilleure serait de commencer  utiliser un
   paquetage qui manipulerait une destruction  recyclable  en
   fournissant une commande qui ne s'appellerait pas rm. Pour plus de
   dtails, voir Peek _et al_ (1993) (voir la section Bibliographie et
   remerciements). Cette solution a cependant l'inconvnient d'encourager
   les utilisateurs  avoir une attitude nonchalante vis--vis de la
   destruction, au lieu de l'attitude circonspecte qui est souvent
   ncessaire sous Unix.

3.  quel taux de rcupration puis-je m'attendre ?

   a dpend. Parmi les problmes concernant la rcupration de fichiers
   dans un systme d'exploitation de haute qualit, multi-tches et
   multi-utilisateurs comme Linux, il se trouve que vous ne savez jamais
   quand quelqu'un veut crire sur le disque. Donc, quand le systme
   d'exploitation reoit l'ordre de supprimer un fichier, il suppose
   libres les blocs utiliss par ce fichier au moment d'allouer de
   nouveau de la place pour un nouveau fichier (c'est un exemple typique
   d'un principe gnral d'Unix : le noyau et les outils associs
   supposent que les utilisateurs ne sont pas des idiots). En gnral,
   plus votre machine est utilise, moins vous avez de chances de
   rcuprer vos fichiers avec succs.

   De plus, la fragmentation du disque peut affecter la facilit de
   rcupration. Si la partition contenant les fichiers supprims est
   trs fragmente, vous avez peu de chances de pouvoir lire un fichier
   entier.

   Si votre machine, comme la mienne, est effectivement une station
   destine  un seul utilisateur, et que vous n'utilisiez pas
   intensivement le disque au moment fatal de la destruction, je
   m'attendrais  un taux de rcupration du mme ordre de grandeur que
   dcrit prcdemment. J'ai rcupr presque 94 % des fichiers, intacts
   (et il s'agissait de fichiers binaires, notez bien). Si vous obtenez
   plus de 80 %, vous pouvez tre plutt content de vous.

4. Bon, alors comment je rcupre un fichier ?

   La procdure consiste principalement en la recherche de donnes dans
   le priphrique de la partition en mode caractre, et en le fait de la
   rendre  nouveau visible par le systme d'exploitation. Il y a
   principalement deux manires de le faire : la premire consiste 
   modifier le systme de fichier existant de telle faon que les inodes
   supprims aient leur indicateur  supprim  retir, et esprer que
   les donnes retombent comme par magie  leur place. L'autre mthode,
   plus sre mais plus lente, est de rechercher o se trouvent les
   donnes dans la partition et de les crire dans un nouveau fichier.

   Vous devez suivre plusieurs tapes avant de commencer votre tentative
   de rcupration ; voir les sections Dmonter le systme de fichiers,
   Prparer la modification directe des inodes et Prparer l'criture 
   un autre endroit pour plus de dtails. Pour dcouvrir comment
   rcuprer rellement vos fichiers, voir les sections Trouver les
   inodes supprims, Obtenir des dtails sur les inodes, Rcuprer des
   blocs de donnes et Modifier les inodes directement.

5. Dmonter le systme de fichiers

   Quelle que soit la mthode que vous choisissiez, la premire tape
   consiste  dmonter le systme de fichiers contenant les fichiers
   supprims. Je vous conseille fortement de rfrner toute envie de
   bricoler un systme de fichiers mont. Cette tape doit tre effectue
   _le plus tt possible_, ds que vous vous tes rendu compte que les
   fichiers sont supprims.

   La mthode la plus simple est la suivante : en supposant que les
   fichiers supprims soient dans la partition /usr, tapez :

# umount /usr

   Vous pouvez cependant avoir besoin de garder certaines donnes
   disponibles dans /usr. Dans ce cas, remontez-le en mode lecture
   seule :

# mount -o ro,remount /usr

   Si les fichiers supprims taient dans la partition racine, vous
   devrez ajouter une option -n, afin d'empcher que l'opration de
   montage ne dclenche une criture dans /etc/mtab :

# mount -n -o ro,remount /

   Indpendamment de tout cela, il est possible qu'un autre processus
   utilise  ce moment-l ce systme de fichier (ce qui fera chouer le
   montage avec une erreur du genre _resource busy_). Il y a un programme
   qui peut envoyer un signal  tout processus utilisant un fichier ou
   point de montage donn : c'est fuser. Pour la partition /usr, essayez
   ceci :

# fuser -v -m /usr

   Cela aura pour effet d'afficher la liste des processus concerns. En
   admettant qu'aucun d'entre eux n'est vital, vous pouvez taper

# fuser -k -v -m /usr

   afin d'envoyer  chaque processus un SIGKILL (qui le tuera
   d'autorit), ou, par exemple,

# fuser -k -TERM -v -m /usr

   pour envoyer plutt  chacun un SIGTERM (qui priera le processus de
   terminer proprement).

6. Prparer la modification directe des inodes

   Mon conseil ? Ne faites pas a. Je ne pense vraiment pas qu'il soit
   raisonnable d'esprer un rsultat en jouant avec un systme de
   fichiers  un si bas niveau. Du reste, vous ne pourrez rcuprer de
   faon fiable que les 12 premiers blocs de chaque fichier. Donc, si
   vous avez des fichiers longs  rcuprer, vous devrez de toute faon
   utiliser l'autre mthode (mais lisez tout de mme la section Cela
   va-t-il se simplifier dans l'avenir~? pour plus d'information).

   Si vous sentez que vous devez le faire de cette manire, je vous
   conseille de copier les donnes de la partition en mode caractre dans
   une autre partition, puis monter le tout en utilisant le priphrique
   boucle (_loopback device_) :

# cp /dev/hda5 /root/working
# mount -t ext2 -o loop /root/working /mnt

   (Notez que les anciennes versions de mount peuvent avoir des problmes
   pour faire cela. Si votre mount ne fonctionne pas, je vous recommande
   fortement de vous procurer la dernire version, ou tout au moins la
   version 2.7, car plusieurs versions plus anciennes ont de graves
   problmes de scurit).

   Le but de la manoeuvre est que, quand vous aurez entirement dtruit
   le systme de fichiers (ce que vous ferez trs probablement), il ne
   vous restera plus qu' copier la partition dans l'autre sens et
   repartir  nouveau.

7. Prparer l'criture  un autre endroit

   Vous devez vous assurer d'avoir quelque part une partition de secours.
   Esprons-le, votre systme a plusieurs partitions : peut-tre une
   racine, une /usr, et une /home. Avec tout ce choix, aucun problme :
   crez simplement un nouveau rpertoire dans l'une d'entre elles.

   Si vous n'avez qu'une partition racine dans laquelle vous fourrez
   tout, a risque d'tre un poil plus dlicat. Peut-tre avez-vous une
   partition MS-DOS ou Windows que vous pourriez utiliser ? Ou vous avez
   le gestionnaire _ramdisk_ dans votre noyau, peut-tre en module ? Pour
   utiliser le _ramdisk_ (en supposant que votre noyau soit plus rcent
   que 1.3.48), tapez les commandes suivantes :

# dd if=/dev/zero of=/dev/ram0 bs=1k count=2048
# mke2fs -v -m 0 /dev/ram0 2048
# mount -t ext2 /dev/ram0 /mnt

   Cela a pour effet de crer un volume _ramdisk_ de 2 Mo, et de le
   monter en /mnt.

   Un petit mot d'avertissement : si vous utilisez kerneld (ou son
   remplaant kmod avec les noyaux 2.2.x et les derniers 2.1.x) pour
   charger et dcharger automatiquement les modules du noyau, alors ne
   dmontez pas le _ramdisk_ tant que vous n'avez pas copi tous les
   fichiers qu'il contient sur un support non volatile. Une fois que vous
   l'aurez dmont, kerneld suppose qu'il peut dcharger le module (aprs
   la priode d'attente habituelle), et, ds qu'il l'a fait, la mmoire
   est rutilise par d'autres lments du noyau, causant la perte
   irrmdiable des heures de travail que vous aurez passes  rcuprer
   soigneusement vos donnes.

   Si vous avez un lecteur Zip, Jaz, ou LS-120, ou quelque chose
   d'quivalent, il s'agit probablement d'une bonne place pour une
   partition de secours. Sinon, il faudra faire avec les disquettes.

   Une autre chose dont vous devriez avoir besoin est un programme
   capable de lire les donnes ncessaires en plein milieu du
   priphrique contenant la partition.  la rigueur, dd pourrait le
   faire, mais pour lire  partir de, disons, 600 Mo dans une partition
   de 800 Mo, dd tient  lire les 600 premiers mgaoctets, quitte  les
   ignorer, et il va y passer un temps non ngligeable, mme sur des
   disques rapides. Pour viter cela, j'ai crit un programme qui peut se
   positionner en plein milieu de la partition. Il s'appelle fsgrab ;
   vous pouvez trouver le paquetage des sources sur ma page, ou sur
   Metalab (et ses miroirs). Si vous souhaitez utiliser cette mthode, la
   suite de ce mini-HOWTO suppose que vous avez fsgrab.

   Si aucun des fichiers que vous voulez rcuprer n'occupe plus de 12
   blocs (o un bloc occupe habituellement un kilooctet), alors vous
   n'aurez pas besoin de fsgrab.

   Si vous avez besoin de fsgrab mais n'en voulez pas, il est fort simple
   de traduire une ligne de commande avec fsgrab en une avec dd. Si on a

     fsgrab -c _count_ -s _skip_ _device_

   alors la commande dd correpondante (et gnralement beaucoup plus
   lente) est

     dd bs=1k if=_device_ count=_count_ skip=_skip_

   Je dois vous avertir que, bien que fsgrab ait parfaitement fonctionn
   pour moi, je ne puis prendre aucune responsabilit sur son
   comportement. C'tait vraiment une bidouille rapide et sale pour
   arriver  mes fins. Pour plus de dtails sur l'absence de garantie,
   consultez la section _No Warranty_ dans le fichier COPYING inclus dans
   la distribution (li s'agit de la GPL, la licence publique gnrale
   GNU).

8. Trouver les inodes supprims

   L'tape suivante consiste  demander au systme de fichiers quels
   inodes ont t rcemment librs. C'est une tche que vous pouvez
   accomplir avec debugfs. Lancez debugfs avec le nom du priphrique sur
   lequel le systme de fichiers rside :

# debugfs /dev/hda5

   Si vous souhaitez modifier les inodes directement, ajoutez une option
   -w de manire  activer l'criture sur le systme de fichiers :

# debugfs -w /dev/hda5

   La commande debugfs permettant de trouver les inodes dtruits est
   lsdel. Donc, tapez la commande suivante  l'invite :

debugfs:  lsdel

   Aprs moult grincements et gmissements du disque, une longue liste
   est envoye par un _pipe_  votre _pager_ favori (la valeur de
   $PAGER). Maintenant vous aurez envie d'en sauver une copie autre part.
   Si vous avez less, vous pouvez taper -o suivi du nom du fichier qui
   devra contenir le rsultat. Sinon, vous devrez vous arranger pour
   envoyer la sortie ailleurs. Essayez ceci :

debugfs:  quit
# echo lsdel | debugfs /dev/hda5 > lsdel.out

   Maintenant, d'aprs la date et l'heure de la suppression, la taille,
   le type et les indications numriques des permissions et propritaire,
   vous devez deviner quelles inodes supprims vous voulez. Avec un peu
   de chance, vous les trouverez tout de suite parce c'est le gros paquet
   que vous avez supprim il y a  peine cinq minutes. Sinon, prenez bien
   garde en allant pcher dans la liste.

   Je vous suggre, autant que possible, d'imprimer la liste des inodes
   que vous voulez rcuprer. Cela vous facilitera nettement la vie.

9. Obtenir des dtails sur les inodes

   debugfs a une commande stat, qui imprime des dtails sur un inode.
   Utilisez la commande pour chacun des inodes de votre liste 
   rcuprer. Par exemple, si vous tes intress par l'inode numro
   148003, essayez ceci :

debugfs:  stat <148003>
Inode: 148003   Type: regular    Mode:  0644   Flags: 0x0   Version: 1
User:   503   Group:   100   Size: 6065
File ACL: 0    Directory ACL: 0
Links: 0   Blockcount: 12
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x31a9a574 -- Mon May 27 13:52:04 1996
atime: 0x31a21dd1 -- Tue May 21 20:47:29 1996
mtime: 0x313bf4d7 -- Tue Mar  5 08:01:27 1996
dtime: 0x31a9a574 -- Mon May 27 13:52:04 1996
BLOCKS:
594810 594811 594814 594815 594816 594817
TOTAL: 6

   Si vous avez de nombreux fichiers  rcuprer, vous souhaiterez
   automatiser tout cela. En suposant que votre liste (d'aprs lsdel)
   d'inodes  rcuprer est dans lsdel.out, essayez ceci :

# cut -c1-6 lsdel.out | grep "[0-9]" | tr -d " " > inodes

   Ce nouveau fichier inodes contient uniquement les numros des inodes 
   rcuprer,  raison d'un par ligne. On le sauvegarde parce qu'il va
   nous tre srement trs utile par la suite. Il ne vous reste plus qu'
   taper :

# sed 's/^.*$/stat <\0>/' inodes | debugfs /dev/hda5 > stats

   et stats contient la sortie de toutes les commandes stat.

10. Rcuprer les blocs de donnes

   Cette partie est soit trs facile, soit nettement moins, selon que les
   fichiers que vous essayez de rcuprer occupent moins ou plus de 12
   blocs.

10.1 Les fichiers courts

   Si le fichier n'occupait pas plus de 12 blocs, alors les numros de
   blocs o sont situes toutes ses donnes sont crits dans l'inode :
   vous pouvez les lire directement sur la sortie de stat correspondant 
   l'inode. De surcrot, debugfs a une commande qui automatise cette
   tche. Pour reprendre l'exemple prcdent :

debugfs:  stat <148003>
Inode: 148003   Type: regular    Mode:  0644   Flags: 0x0   Version: 1
User:   503   Group:   100   Size: 6065
File ACL: 0    Directory ACL: 0
Links: 0   Blockcount: 12
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x31a9a574 -- Mon May 27 13:52:04 1996
atime: 0x31a21dd1 -- Tue May 21 20:47:29 1996
mtime: 0x313bf4d7 -- Tue Mar  5 08:01:27 1996
dtime: 0x31a9a574 -- Mon May 27 13:52:04 1996
BLOCKS:
594810 594811 594814 594815 594816 594817
TOTAL: 6

   Ce fichier a six blocs. Puisqu'il est en-dessous de la limite des 12,
   nous demandons  debugfs d'crire le fichier dans un nouvel endroit,
   comme par exemple /mnt/recovered.000 :

debugfs:  dump <148003> /mnt/recovered.000

   Bien sr, on peut faire a aussi avec fsgrab ; je le montre ici en
   guise d'exemple d'utilisation :

# fsgrab -c 2 -s 594810 /dev/hda5 > /mnt/recovered.000
# fsgrab -c 4 -s 594814 /dev/hda5 >> /mnt/recovered.000

   Que ce soit avec debugfs ou avec fsgrab, il y aura un peu de dchet 
   la fin de /mnt/recovered.000, mais ce n'est pas trs important. Si
   vous voulez vous en dbarrasser, la mthode la plus simple est de
   prendre le champ Size de l'inode, et le brancher sur l'option bs d'une
   ligne de commande dd.

# dd count=1 if=/mnt/recovered.000 of=/mnt/resized.000 bs=6065

   Bien sr, il est possible qu'un ou plusieurs blocs o tait crit
   votre fichier aient t crass. Si c'est le cas, pas de chance : le
   bloc est mort et enterr (rendez-vous compte, si seulement vous aviez
   dmont plus tt !).

10.2 Les fichiers plus longs

   Les problmes apparaissent lorsque le fichier tient sur plus de 12
   blocs de donnes. Ici, il vaut mieux en savoir un peu sur la manire
   dont sont structurs les systmes de fichiers Unix. Les donnes du
   fichier sont stockes dans des units appeles  blocs . Ces blocs
   peuvent tre numrots squentiellement. Un fichier a galement un 
   inode , o sont places des informations telles que propritaire,
   permissions ou type. Comme les blocs, les inodes sont numrots
   squentiellement, bien que la squence soit diffrente. Une entre de
   rpertoire consiste en un nom de fichier associ  un numro d'inode.

   Mais, si on en restait l, le noyau ne saurait toujours pas trouver
   les donnes correspondant  une entre de rpertoire. Ainsi l'inode
   indique galement l'endroit o se trouvent les blocs de donnes du
   fichier, comme suit :

     * Les numros de blocs des 12 premiers blocs sont indiqus
       directement dans l'inode (on les appelle parfois _blocs
       directs_) ;
     * L'inode contient le numro de bloc d'un _bloc indirect_. Un bloc
       indirect contient les numros de bloc de 256 blocs de donnes
       additionnels ;
     * L'inode contient le numro de bloc d'un _bloc doublement
       indirect_. Un bloc doublement indirect contient les numros de bloc
       de blocs indirects supplmentaires ;
     * L'inode contient le numro de bloc d'un bloc _triplement
       indirect_. Un bloc triplement indirect contient les numros de bloc
       de 256 blocs doublement indirects supplmentaires.

   Relisez bien tout a : je sais que c'est compliqu, mais c'est
   important, aussi.

   Maintenant, l'implantation du noyau pour toutes les versions actuelles
   (2.0.36 inclue) efface malheureusement tous les blocs indirects (et
   doublement indirects, etc.) lors de la suppression d'un fichier.
   Alors, si votre fichier occupait plus de 12 blocs, vous n'tes pas
   garanti de pouvoir retrouver les numros de tous les blocs dont vous
   avez besoin (sans parler de leur contenu).

   La seule mthode que j'aie pu trouver jusqu'ici consiste  supposer
   que le fichier n'est pas fragment : s'il l'est, vous aurez des
   ennuis. En supposant que le fichier n'est pas fragment, il y a
   plusieurs dispositions de blocs de donnes, selon le nombre de blocs
   de donnes utiliss par le fichier :

   _0  12_
          les numros de bloc sont indiqus dans l'inode, comme dcrit
          prcdemment ;

   _13  268_
          aprs les blocs directs, comptez un pour le bloc indirect, puis
          vous avez 256 blocs de donnes ;

   _269  65804_
          comme avant, il y a 12 blocs directs, un bloc indirect
          (inutile), et 256 blocs. Ils sont suivis d'un bloc doublement
          indirect (inutile), et 256 rptitions de : un bloc indirect
          (inutile) et 256 blocs de donnes ;

   _65805 ou plus_
          la disposition des 65804 premiers blocs est identique  ce qui
          est dcrit di-dessus. Suivent un bloc triplement indirect
          (inutile) et 256 rptitions d'une squence  doublement
          indirect . Chaque squence doublement indirecte consiste en un
          bloc doublement indirect (inutile), suivi de 256 rptitions
          de : un bloc indirect (inutile) et 256 blocs de donnes.

   Bien entendu, mme si ces blocs sont supposs corrects, rien ne
   garantit que les donnes qu'ils contiennent sont intactes. De plus,
   plus le fichier est long, moins vous avez de chances qu'il ait pu tre
   crit dans le systme de fichiers sans fragmentation raisonnable (sauf
   dans certaines circonstances particulires).

   Notez que j'ai suppos depuis le dbut que vos blocs occupaient la
   taille de 1024 octets, c'est--dire la valeur standard. Si vos blocs
   sont plus grands, une partie des nombres crits plus haut doivent tre
   changs. Typiquement, puisque chaque numro de bloc occupe 4 octets,
   le nombre de numros de bloc pouvant tre placs dans chaque bloc
   indirect est taille_du_bloc/4. Donc, chaque fois que le nombre 256
   apparat dans la dicussion qui prcde, remplacez-le par
   taille_du_bloc/4. Les limitations  nombre de blocs requis  devront
   galement tre modifies.

   Examinons un exemple de rcupration de fichier plus long.

debugfs:  stat <1387>
Inode: 148004   Type: regular    Mode:  0644   Flags: 0x0   Version: 1
User:   503   Group:   100   Size: 1851347
File ACL: 0    Directory ACL: 0
Links: 0   Blockcount: 3616
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x31a9a574 -- Mon May 27 13:52:04 1996
atime: 0x31a21dd1 -- Tue May 21 20:47:29 1996
mtime: 0x313bf4d7 -- Tue Mar  5 08:01:27 1996
dtime: 0x31a9a574 -- Mon May 27 13:52:04 1996
BLOCKS:
8314 8315 8316 8317 8318 8319 8320 8321 8322 8323 8324 8325 8326 8583
TOTAL: 14

   Il semble y avoir de bonnes chances pour que ce fichier ne soit pas
   fragment : de faon vidente, les 12 premiers blocs lists dans
   l'inode (qui sont tous des blocs de donnes) sont contigus. Nous
   pouvons donc commencer par rcuprer ces blocs :

# fsgrab -c 12 -s 8314 /dev/hda5 > /mnt/recovered.001

   Maintenant, le bloc suivant list dans l'inode, 8326, est un bloc
   indirect, que nous pouvons ignorer. Mais nous nous fions  notre
   intuition qu'il sera suivi de 256 blocs de donnes (du numro 8327 au
   numro 8582).

# fsgrab -c 256 -s 8327 /dev/hda5 >> /mnt/recovered.001

   Le dernier bloc list dans l'inode est le 8583. Notez que a ressemble
   toujours bien  un fichier contigu : le numro du dernier bloc que
   nous ayons crit tait le 8582, donc 8327 + 255. Ce bloc 8583 est un
   bloc doublement indirect, que nous pouvons ignorer. Il est suivi par
   jusqu' 256 rptitions d'un bloc indirect (ignor) suivi de 256 blocs
   de donnes. Aprs un petit calcul mental, on en dduit les commandes
   suivantes. Remarquez qu'on saute le bloc doublement indirect 8583 et
   le bloc indirect 8584, qui suivent immdiatement (esprons-le) et
   qu'on commence directement  lire les donnes depuis le bloc 8585.

# fsgrab -c 256 -s 8585 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 8842 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 9099 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 9356 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 9613 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 9870 /dev/hda5 >> /mnt/recovered.001

   En rassemblant tout, on voit qu'on a crit depuis le dbut 12 + (7 *
   256) blocs, c'est--dire 1804. La commande  stat  nous a indiqu
   pour l'inode un  _blockcount_  de 3616 ; mais ces blocs occupaient
   malheureusement 512 octets (un reliquat d'Unix), ce que nous voulons
   rellement est alors 3616/2 = 1808 blocs de 1024 octets. Cela signifie
   que nous avons seulement besoin de quatre blocs de plus. Le dernier
   bloc de donnes crit portait le numro 10125. De la mme faon que
   depuis le dbut, on saute un bloc indirect (numro 10126) ; on peut
   alors crire ces quatre derniers blocs.

# fsgrab -c 4 -s 10127 /dev/hda5 >> /mnt/recovered.001

   Et maintenant, avec un peu de chance, le fichier complet a t
   rcupr avec succs.

11. Modifier les inodes directement

   Cette mthode est apparemment beaucoup plus facile. Cependant, comme
   soulign plus haut, elle ne peut pas venir  bout de fichiers occupant
   plus de 12 blocs.

   Pour chaque inode que vous voulez rcuprer, vous devez mettre  1 le
   nombre de liens, et  0 la date de suppression. Cela peut tre fait
   grce  la commande mi (modifier inode) de debugfs. Voici un exemple
   de sortie concernant la modification de l'inode 148003 :

debugfs:  mi <148003>
                        Mode    [0100644]
                     User ID    [503]
                    Group ID    [100]
                        Size    [6065]
               Creation time    [833201524]
           Modification time    [832708049]
                 Access time    [826012887]
               Deletion time    [833201524] 0
                  Link count    [0] 1
                 Block count    [12]
                  File flags    [0x0]
                   Reserved1    [0]
                    File acl    [0]
               Directory acl    [0]
            Fragment address    [0]
             Fragment number    [0]
               Fragment size    [0]
             Direct Block #0    [594810]
             Direct Block #1    [594811]
             Direct Block #2    [594814]
             Direct Block #3    [594815]
             Direct Block #4    [594816]
             Direct Block #5    [594817]
             Direct Block #6    [0]
             Direct Block #7    [0]
             Direct Block #8    [0]
             Direct Block #9    [0]
            Direct Block #10    [0]
            Direct Block #11    [0]
              Indirect Block    [0]
       Double Indirect Block    [0]
       Triple Indirect Block    [0]

   C'est--dire que je mets  0 la date de suppression et le nombre de
   liens  1, puis j'envoie juste un retour chariot pour chacun des
   autres champs. D'accord, ce n'est pas trs souple si vous avez
   beaucoup de fichiers  rcuprer, mais je pense que vous pourrez faire
   face. Si vous vouliez du velours, il fallait utiliser un  systme
   d'exploitation  graphique avec une jolie  corbeille .

    propos, le texte de sortie de mi indique un champ  cration 
   (_creation time_). Il est totalement mensonger (ou en tout cas
   trompeur) ! En fait, sur un systme de fichiers Unix, vous ne pouvez
   pas dterminer quand un fichier a t cr. Le champ st_ctime d'une
   struct stat fait rfrence  la date de modification de l'inode
   (_inode change time_), c'est--dire la dernire fois qu'un quelconque
   des dtails de l'inode a t chang. Si finit la lessons d'huy.

   Notez que les versions plus rcentes de debugfs que celle que
   j'utilise n'incluent probablement pas certains des champs de la liste
   donne plus haut (typiquement Reserved1 et des champs sur les
   fragments).

   Une fois que vous aurez modifi les inodes, vous pourrez quitter
   debugfs et taper :

# e2fsck -f /dev/hda5

   L'ide est que chacun des fichiers supprims a t littralement 
   d-supprim , mais qu'aucun d'entre eux n'apparat en entre de
   rpertoire. Le programme e2fsck peut le dtecter, et ajoutera une
   entre dans le rpertoire /lost+found du systme de fichiers (Donc, si
   la partition est normalement monte dans /usr, les fichiers vont
   apparatre dans /usr/lost+found). Tout ce qui reste  faire est de
   redonner son nom  chaque fichier d'aprs son contenu, et le remettre
    sa place dans l'arborescence du systme de fichiers.

   Quand vous lancerez e2fsck, vous obtiendrez des messages
   d'information, ainsi que des questions  propos des problmes 
   rparer. Rpondez oui (_yes_) partout o vous voyez _`summary
   information'_ ou  chaque rfrence aux inodes que vous avez modifis.
   Tout le reste vous regarde, bien qu'il soit en gnral une bonne ide
   de rpondre oui  toutes les questions. Lorsque e2fsck a termin, vous
   pouvez remonter le systme de fichiers.

   En fait, il y a un autre moyen que de demander  e2fsck de laisser les
   fichiers dans /lost+found : vous pouvez utiliser debugfs pour crer un
   lien vers l'inode dans le systme de fichiers. Utilisez la commande
   link de debugfs quand vous avez fini de modifier l'inode.

debugfs:  link <148003> toto.txt

   Ceci cre un fichier appel toto.txt dans ce que debugfs suppose tre
   le rpertoire courant ; toto.txt sera votre fichier. Vous aurez quand
   mme besoin de lancer e2fsck pour corriger le _`summary information'_,
   le nombre de blocs, etc.

12. Cela va-t-il se simplifier dans l'avenir ?

   Oui. En fait, je pense que c'est dj le cas. Bien qu'au moment o ces
   lignes sont crites (2 fvrier 1999), les noyaux stables actuels (la
   srie 2.0.x) effacent les blocs indirects, ce n'est plus le cas des
   noyaux de dveloppement 2.1.x, ni des noyaux stables 2.2.x, dont le
   2.2.1 qui vient d'tre diffus ; nous allons voir apparatre des
   distributions  base de noyaux 2.2.x d'ici un ou deux mois.

   Une fois cette limitation retire des noyaux stables, bon nombre de
   mes objections au fait de modifier les inodes  la main disparatront.
   Il sera galement possible d'utiliser la commande dump de debugfs sur
   des fichiers longs, et d'utiliser d'autres outils de rcupration.

13. Existe-t-il des outils qui automatisent le processus ?

   En fait, il y en a. Hlas, je crains qu'ils souffrent du mme problme
   que la technique de modification manuelle des inodes : les blocs
   indirects sont irrcuprables. Cependant, selon la probabilit que
   cela ne soit plus un problme d'ici peu, a vaut srement le coup de
   chercher ces programmes maintenant.

   J'ai crit un utilitaire nomm e2recover, qui est essentiellement un
   enrobage Perl  fsgrab. Il fait un effort raisonnable pour grer les
   blocs indirects effacs, et semble trs bien fonctionner en l'absence
   de fragmentation. Il en profite pour remettre les permissions (et,
   quand c'est possible, le propritaire) des fichiers rcuprs, et
   s'assure mme que les fichiers rcuprs soient  la bonne taille.

   J'ai initialement crit e2recover pour la toute proche mise  jour de
   ce Howto ; malheureusement cela signifie que tous les renseignements
   utiles sur e2recover sont aussi prvus pour cette mise  jour. En
   attendant, il devrait s'avrer quand mme utile ds maintenant ; vous
   pouvez le tlcharger depuis ma page, et prochainement sur Metalab.

   Scott D. Heavner est l'auteur de lde, (`Linux Disk Editor'). lde peut
   servir aussi bien d'diteur binaire de disque, que d'un quivalent de
   debugfs pour les systmes ext2 et minix, et mme pour les systmes xia
   (bien que le support xia ne soit plus disponible dans les noyaux 2.1.x
   et 2.2.x). Il dispose de fonctionnalits pour faciliter la
   rcupration, comme le parcours de la liste des blocs, et la recherche
   dans le contenu du disque. Il possde galement une documentation sur
   les concepts de base des systmes de fichiers particulirement utile,
   ainsi qu'un document expliquant comment l'utiliser afin de rcuprer
   des fichiers supprims. La version 2.4 de lde est disponible sur
   Metalab et ses mirroirs, et sur la page de son auteur.

   Une autre possibilit est fournie par le GNU Midnight Commander, mc.
   C'est un gestionnaire de fichiers en plein cran, inspir autant que
   je le sache d'un certain programme MS-DOS couramment dsign sous le
   nom de  nc . mc supporte la souris dans la console Linux et dans un
   xterm, et fournit des systmes de fichiers virtuels qui permettent des
   trucs du genre de se dplacer dans une archive Tar. Parmi ses systmes
   de fichiers virtuels, il en est un concernant la rcupration sous
   Ext2. Tout a semble trs commode  manipuler, mais je dois avouer que
   que je ne l'ai jamais utilis moi-mme -- je prfre les bonnes
   vieilles commandes _shell_. Apparemment il faut configurer le
   programme avec l'option --with-ext2undel ; vous aurez galement besoin
   des bibliothques de dveloppement et des fichiers d'en-tte
   (_include_) qui viennent avec le paquetage e2fsprogs. La version fournie
   par Debian GNU/Linux est ainsi compil ; c'est peut-tre le cas pour
   d'autres distributions. Une fois que le programme est compil, vous
   pouvez y taper cd undel:/dev/hda5/, et obtenir, sous forme de contenu
   de rpertoire, le catalogue des fichiers supprims. Comme la plupart
   des outils actuels de rcupration, il gre trs mal les blocs
   indirects effacs -- la plupart du temps il ne rcupre que les 12
   premiers Ko des gros fichiers.

   La dernire version peut tre rcupre depuis le site ftp officiel.

14. Achev d'imprimer...

   J'ai l'intention de produire des mises  jour rgulires de ce
   document, tant que j'aurai  la fois suffisamment de temps pour le
   faire et quelque chose d'intressant  dire. Ceci signifie que je suis
   avide de commentaires de la part de mes lecteurs. Ma rdaction
   peut-elle tre plus claire ? Pouvez-vous penser  quelque chose qui
   pourrait rendre l'affaire plus simple ? Existe-t-il un nouvel outil
   qui puisse faire tout cela automatiquement ?

   Quoi qu'il en soit : si vous avez quoi que ce soit  dire,  propos de
   ce document ou des outils fsgrab et e2recover, envoyez-moi un mot  :

   aaronc@pobox.com.

15. Remerciements et bibliographie

     _Si j'ai vu plus loin que d'autres, c'est parce que j'tais hiss
     sur des paules de gants_ (Isaac Newton)

   Une grande partie de ce mini-Howto est drive d'un article post sur
   le groupe de _news_ comp.os.linux.misc par Robin Glover
   swrglovr@met.rdg.ac.uk.

   Je voudrais remercier Robin de m'avoir gracieusement autoris 
   reprendre ses ides dans ce mini-Howto.

   Je voudrais galement profiter de l'occasion pour remercier une fois
   de plus toutes les personnes qui m'ont contact  propos de ce Howto.
   Ce sont les remerciements chaleureux que l'on reoit qui justifient la
   peine que l'on se donne.

   Quelques rfrences bibliographiques :

     * _Frisch_, leen (1995), _Essential System Administration_, second
       edition, O'Reilly and Associates, Inc., ISBN : 1-56592-127-5.
     * _Garfinkel_, Simson, Daniel _Weise_ et Steven _Strassmann_ (1994),
       _The Unix-Haters Handbook_, IDG Books, ISBN : 1-56884-203-1. Ce
       livre est compos pour la plus grande partie de pleurs
       d'adolescents qui pensent que _leur_ systme d'exploitation est
       tellement mieux qu'Unix, et le reste ne s'applique pas si vous
       avez de bons programmes en espace utilisateur tels que les outils
       GNU. Mais il y a quelques pis de bl parmi la paille ; par
       exemple, la discussion autour de la facilit d'effacement de
       fichier sous Unix mrite qu'on s'y arrte.
     * _Glover_, Robin (31 Jan 1996), _HOW-TO : undelete linux files
       (ext2fs/debugfs)_, comp.os.linux.misc Usenet posting.
     * _Peek_, Jerry, Tim _O'Reilly_, Mike _Loukides_ _et al_ (1993),
       _UNIX Power Tools_, O'Reilly and Associates, Inc./Random House,
       Inc., ISBN : 0-679-79073-X.

16. Bla-bla juridique

   Toutes les marques dposes sont la proprit de leurs auteurs
   respectifs. Spcifiquement :

     * _MS-DOS_ et _Windows_ sont des marques dposes de Microsoft ;
     * _UNIX_ est une marque dpose de _the Open Group_ ;
     * _Linux_ est une marque dpose de Linus Torvalds aux USA et dans
       quelques autres pays.

   Ce document est Copyright  1997, 1999 Aaron Crane aaronc@pobox.com.
   Il peut tre librement et entirement redistribu  condition d'y
   inclure toujours la totalit de cette note de copyright, mais ne peut
   pas tre modifi sans l'autorisation, soit de son auteur, soit du
   coordinateur du Linux Documentation Project. Une drogation est
   cependant accorde dans le cas de la copie de courts extraits sans
   modification pour des revues ou une citation ; dans ces circonstances,
   les sections peuvent tre reproduites accompagnes d'une citation
   approprie mais sans cette note de copyright.

   L'auteur demande, mais n'exige pas, que des parties souhaitant vendre
   des copies de ce document, sur un _medium_ lisible par un ordinateur
   ou par un humain, informent de leurs intentions, soit l'auteur, soit
   le coordinateur des HOWTO Linux.

   Le coordinateur des HOWTO Linux est actuellement Tim Bynum
   linux-howto@metalab.unc.edu.
