  Linux Ext2fs Undeletion mini-HOWTO
  Aaron Crane, aaronc@pobox.com
  v1.3, 2 Fvrier 1999

  (Adaptation franaise par Miodrag Vallat <mailto:miodrag@multima
  nia.com>, anciennement par Graud Canet <mailto:canet@labri.u-bor
  deaux.fr> et Sylviane Regnault <mailto:regnault@axpcalc.crpp.u-bor
  deaux.fr>).  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 _o_e_u_v_r_e _m_a__t_r_e_s_s_e !  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...
  ______________________________________________________________________

  Table des matires


  1. Introduction

     1.1 Historique des rvisions
        1.1.1 Nouveauts de la version 1.1
        1.1.2 Nouveauts de la version 1.2
        1.1.3 Nouveauts de la version 1.3
     1.2 O trouver ce document

  2. Comment ne pas supprimer de fichiers

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

  4. Bon, alors comment je rcupre un fichier ?

  5. Dmonter le systme de fichiers

  6. Prparer la modification directe des inodes

  7. Prparer l'criture  un autre endroit

  8. Trouver les inodes supprims

  9. Obtenir des dtails sur les inodes

  10. Rcuprer les blocs de donnes

     10.1 Les fichiers courts
     10.2 Les fichiers plus longs

  11. Modifier les inodes directement

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

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

  14. Achev d'imprimer...

  15. Remerciements et bibliographie

  16. Bla-bla juridique


  ______________________________________________________________________

  11..  IInnttrroodduuccttiioonn

  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
  _e_x_i_g_e 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 _r_o_o_t, 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
  _r_o_o_t.  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..11..  HHiissttoorriiqquuee ddeess rrvviissiioonnss

  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'').


  11..11..11..  NNoouuvveeaauuttss ddee llaa vveerrssiioonn 11..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 <http://pobox.com/~aaronc/tech/fsgrab-1.2.tar.gz> et sur Metalab
  <http://metalab.unc.edu/pub/Linux/utils/file/> (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.


  11..11..22..  NNoouuvveeaauuttss ddee llaa vveerrssiioonn 11..2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.).


  11..11..33..  NNoouuvveeaauuttss ddee llaa vveerrssiioonn 11..3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1..22..  OO ttrroouuvveerr ccee ddooccuummeenntt

  La version officielle la plus rcente de ce document devrait tre
  disponible au format texte auprs du site du Linux Documentation
  Project <http://metalab.unc.edu/LDP/> (et ses miroirs).  La dernire
  version est galement disponible sur ma page
  <http://pobox.com/~aaronc/> sous divers formats :


    source SGML <http://pobox.com/~aaronc/tech/e2-undel/howto.sgml>,
     tel que je l'ai crit ;

    HTML <http://pobox.com/~aaronc/tech/e2-undel/html/>, gnr
     automatiquement depuis le source SGML ;

    format texte <http://pobox.com/~aaronc/tech/e2-undel/howto.txt>,
     galement gnr automatiquement depuis le source SGML.


  22..  CCoommmmeenntt nnee ppaass ssuupppprriimmeerr ddee ffiicchhiieerrss

  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) :


       FFAAIITTEESS DDEESS SSAAUUVVEEGGAARRDDEESS


  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
  _c_o_n_f_o_r_m_e_r.  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 _r_o_o_t 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  (_a_p_p_e_n_d_-_o_n_l_y) : 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  (_i_m_m_u_t_a_b_l_e), qui ne peut tre
  plac ou retir qu'en tant que _r_o_o_t.  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  (_u_n_d_e_l_e_t_a_b_l_e,
  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 _t_o_u_s les fichiers  supprimer).  En effet, certaines
  versions de la distribution Red Hat <http://www.redhat.com/> le font
  par dfaut pour tous les utilisateurs, y compris _r_o_o_t. 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 _e_t _a_l (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3..   qquueell ttaauuxx ddee rrccuupprraattiioonn ppuuiiss--jjee mm''aatttteennddrree ??

  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4..  BBoonn,, aalloorrss ccoommmmeenntt jjee rrccuupprree uunn ffiicchhiieerr ??

  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5..  DDmmoonntteerr llee ssyyssttmmee ddee ffiicchhiieerrss

  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
  _l_e _p_l_u_s _t__t _p_o_s_s_i_b_l_e, 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 _r_e_s_o_u_r_c_e _b_u_s_y). 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6..  PPrrppaarreerr llaa mmooddiiffiiccaattiioonn ddiirreeccttee ddeess iinnooddeess

  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 (_l_o_o_p_b_a_c_k _d_e_v_i_c_e) :



       # 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7..  PPrrppaarreerr ll''ccrriittuurree  uunn aauuttrree eennddrrooiitt

  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 _r_a_m_d_i_s_k dans votre noyau, peut-tre en module ? Pour
  utiliser le _r_a_m_d_i_s_k (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 _r_a_m_d_i_s_k 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 _r_a_m_d_i_s_k 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
  <http://pobox.com/~aaronc/tech/fsgrab-1.2.tar.gz>, ou sur Metalab
  <http://metalab.unc.edu/pub/Linux/utils/file/> (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 _c_o_u_n_t -s _s_k_i_p _d_e_v_i_c_e


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


       dd bs=1k if=_d_e_v_i_c_e count=_c_o_u_n_t skip=_s_k_i_p


  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 _N_o _W_a_r_r_a_n_t_y dans le fichier COPYING inclus dans
  la distribution (li s'agit de la GPL, la licence publique gnrale
  GNU).


  88..  TTrroouuvveerr lleess iinnooddeess ssuupppprriimmss

  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 _p_i_p_e  votre _p_a_g_e_r 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9..  OObbtteenniirr ddeess ddttaaiillss ssuurr lleess iinnooddeess

  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.


  1100..  RRccuupprreerr lleess bbllooccss ddee ddoonnnneess

  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.


  1100..11..  LLeess ffiicchhiieerrss ccoouurrttss

  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 !).


  1100..22..  LLeess ffiicchhiieerrss pplluuss lloonnggss

  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 _b_l_o_c_s _d_i_r_e_c_t_s) ;

    L'inode contient le numro de bloc d'un _b_l_o_c _i_n_d_i_r_e_c_t.  Un bloc
     indirect contient les numros de bloc de 256 blocs de donnes
     additionnels ;

    L'inode contient le numro de bloc d'un _b_l_o_c _d_o_u_b_l_e_m_e_n_t _i_n_d_i_r_e_c_t.
     Un bloc doublement indirect contient les numros de bloc de blocs
     indirects supplmentaires ;

    L'inode contient le numro de bloc d'un bloc _t_r_i_p_l_e_m_e_n_t _i_n_d_i_r_e_c_t.
     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0  1122
        les numros de bloc sont indiqus dans l'inode, comme dcrit
        prcdemment ;


     1133  226688
        aprs les blocs directs, comptez un pour le bloc indirect, puis
        vous avez 256 blocs de donnes ;


     226699  6655880044
        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 ;


     6655880055 oouu pplluuss
        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  _b_l_o_c_k_c_o_u_n_t  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.


  1111..  MMooddiiffiieerr lleess iinnooddeess ddiirreecctteemmeenntt

  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 
  (_c_r_e_a_t_i_o_n _t_i_m_e). 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 (_i_n_o_d_e
  _c_h_a_n_g_e _t_i_m_e), 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 (_y_e_s) partout o vous voyez _`_s_u_m_m_a_r_y
  _i_n_f_o_r_m_a_t_i_o_n_' 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 _`_s_u_m_m_a_r_y _i_n_f_o_r_m_a_t_i_o_n_',
  le nombre de blocs, etc.


  1122..  CCeellaa vvaa--tt--iill ssee ssiimmpplliiffiieerr ddaannss ll''aavveenniirr ??

  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.


  1133..  EExxiissttee--tt--iill ddeess oouuttiillss qquuii aauuttoommaattiisseenntt llee pprroocceessssuuss ??

  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
  <http://pobox.com/~aaronc/tech/e2-undel/>, 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
  <http://metalab.unc.edu/pub/Linux/system/filesystems/lde-2.4.tar.gz>
  et ses mirroirs, et sur la page de son auteur
  <http://www.geocities.com/CapeCanaveral/Lab/7731/lde.html>.

  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 _s_h_e_l_l.  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 (_i_n_c_l_u_d_e) qui
  viennent avec le paquetage e2fsprogs.  La version fournie par Debian
  GNU/Linux <http://www.debian.org/> 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
  <ftp://ftp.nuclecu.unam.mx/Midnight/devel>.


  1144..  AAcchheevv dd''iimmpprriimmeerr......

  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.




  1155..  RReemmeerrcciieemmeennttss eett bbiibblliiooggrraapphhiiee


       _S_i _j_'_a_i _v_u _p_l_u_s _l_o_i_n _q_u_e _d_'_a_u_t_r_e_s_, _c_'_e_s_t _p_a_r_c_e _q_u_e _j_'__t_a_i_s
       _h_i_s_s_ _s_u_r _d_e_s __p_a_u_l_e_s _d_e _g__a_n_t_s (Isaac Newton)


  Une grande partie de ce mini-Howto est drive d'un article post sur
  le groupe de _n_e_w_s 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 :


    FFrriisscchh, leen (1995), _E_s_s_e_n_t_i_a_l _S_y_s_t_e_m _A_d_m_i_n_i_s_t_r_a_t_i_o_n, second
     edition, O'Reilly and Associates, Inc., ISBN : 1-56592-127-5.

    GGaarrffiinnkkeell, Simson, Daniel WWeeiissee et Steven SSttrraassssmmaannnn (1994), _T_h_e
     _U_n_i_x_-_H_a_t_e_r_s _H_a_n_d_b_o_o_k, IDG Books, ISBN : 1-56884-203-1.  Ce livre
     est compos pour la plus grande partie de pleurs d'adolescents qui
     pensent que _l_e_u_r 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.

    GGlloovveerr, Robin (31 Jan 1996), _H_O_W_-_T_O _: _u_n_d_e_l_e_t_e _l_i_n_u_x _f_i_l_e_s
     _(_e_x_t_2_f_s_/_d_e_b_u_g_f_s_), comp.os.linux.misc Usenet posting.

    PPeeeekk, Jerry, Tim OO''RReeiillllyy, Mike LLoouukkiiddeess _e_t _a_l (1993), _U_N_I_X _P_o_w_e_r
     _T_o_o_l_s, O'Reilly and Associates, Inc./Random House, Inc., ISBN :
     0-679-79073-X.



  1166..  BBllaa--bbllaa jjuurriiddiiqquuee

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


    _M_S_-_D_O_S et _W_i_n_d_o_w_s sont des marques dposes de Microsoft
     <http://www.microsoft.com/> ;

    _U_N_I_X est une marque dpose de _t_h_e _O_p_e_n _G_r_o_u_p
     _<http://www.open.org/> ;

    _L_i_n_u_x 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 _m_e_d_i_u_m 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.
























































