  Linux Ext2fs Undeletion mini-HOWTO
  Aaron Crane, <aaronc@pobox.com>
  v1.2, 4 aout 1997

  (Adaptation   francaise   au   5   janvier   1997   par  Geraud  Canet
  <mailto:canet@labri.u-bordeaux.fr> et Sylviane  Regnault  <mailto:reg-
  nault@axpcalc.crpp.u-bordeaux.fr>).   Imaginez un peu. Vous avez passe
  les trois derniers jours sans dormir, sans manger, sans  meme  prendre
  une  douche.  Votre bidouillomanie compulsive a enfin porte ses fruits
  : vous avez acheve ce programme qui vous apportera gloire  et  admira-
  tion  du monde entier.  Allez, plus qu'a archiver tout ca et l'envoyer
  a Sunsite.  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 detruit votre _o_e_u_v_r_e _m_a_i_t_r_e_s_s_e  !   Mais,
  heureusement,  vous avez de l'aide a portee de main.  Ce document pre-
  sente une discussion de la recuperation de fichiers  supprimes  depuis
  le Second systeme de fichiers etendu ext2fs.  Esperez, peut-etre pour-
  rez-vous distribuer votre programme malgre tout...

  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 recuperer des fichiers supprimes depuis un systeme de fichiers
  ext2fs. Il contient egalement une petite discussion sur  les  manieres
  de commencer par eviter de supprimer des fichiers.

  Mon  but  est naturellement d'en faire une reference utile a tous ceux
  qui ont eu un, disons... accident avec rm ; mais cependant je souhaite
  a  chacun de le lire de toute facon.  On ne sait jamais : un jour, les
  renseignements donnes ici pourraient vous sauver la couenne.

  La lecture de ce texte suppose un minimum  de  connaissances  sur  les
  systemes  de fichiers Unix ; je me suis cependant efforce de le rendre
  accessible a la plupart des utilisateurs de Linux.  Si  vous  etes  un
  tout  debutant,  je  crains que la recuperation de fichiers sous Linux
  _e_x_i_g_e  certaines   connaissances   techniques,   ainsi   que   de   la
  perseverance, au moins dans l'etat actuel des choses.

  Il  vous sera impossible de recuperer des fichiers supprimes depuis un
  systeme de fichiers  ext2  sans  au  moins  un  acces  en  lecture  au
  peripherique  (fichier  special) sur lequel le fichier etait place. En
  general, cela signifie que vous devez etre _r_o_o_t. Vous aurez  egalement
  besoin  de  la  commande  debugfs, du paquetage e2fsprogs, qui devrait
  avoir ete installe par votre distribution.

  Pourquoi ai-je ecrit ceci ? Principalement par experience personnelle,
  souvenir  du  desastre d'un rm -r particulierement insense en tant que
  _r_o_o_t.  J'ai supprime 97 fichiers JPEG dont j'avais besoin et que je ne
  pouvais  certainement  pas  recuperer  par ailleurs.  Suivant quelques
  conseils (voir la section ``Remerciements et  bibliographie'')  et  en
  perseverant  beaucoup,  j'ai  recupere  91  fichiers intacts.  Je suis
  parvenu a en retrouver, au moins en partie, cinq autres  (suffisamment
  pour  voir  quelle  etait  l'image representee par chacun).  Une seule
  n'etait pas affichable, et meme pour celle-la, je suis certain que pas
  plus  de  1024  octets  furent  perdus  (mais helas depuis le debut 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 recuperation que vous pouvez esperer
  pour les fichiers supprimes.

  11..11..  HHiissttoorriiqquuee ddeess rreevviissiioonnss

  Les revisions de ce document (en version anglaise, NdT)  delivrees  au
  public, ainsi que leurs dates de publication, sont les suivantes :
  +o  v1.0, 18 janvier 1997 ;

  +o  v1.1, 23 juillet 1997 (voir ``Nouveautes v1.1'') ;

  +o  v1.2, 4 aout 1997 (voir ``Nouveautes v1.2'').

  11..11..11..

  NNoouuvveeaauutteess ddee llaa vveerrssiioonn 11..11

  Quels  sont  les  nouveautes  de cette version ?  Primo,  la reflexion
  dans l'exemple de la recuperation de fichiers a ete corrigee. Merci  a
  tous  ceux  qui  m'ont  ecrit  pour  me  signaler  mon  erreur  ; cela
  m'apprendra, je l'espere, a faire  plus  attention  en  inventant  des
  sequences interactives.

  Secundo,  la discussion sur le modele de systeme de fichier Unix a ete
  recrite afin d'etre (esperons-le) plus comprehensible.  Je n'en  etais
  pas  entierement satisfait de prime abord, et d'aucuns se sont plaints
  de son manque de clarte.

  Tertio, le  gros-tas-de-tar-gzip-uu-encode  de  fsgrab  au  milieu  du
  fichier  a  ete  retire.  Le programme est desormais disponible sur ma
  page  <http://pobox.com/~aaronc/tech/fsgrab-1.0.tar.gz>  et  va   sans
  tarder        trouver        sa        voie        vers        Sunsite
  <http://sunsite.unc.edu/pub/Linux/utils/disk-management/>   (et    ses
  miroirs).

  Quarto,  le  document  a  ete  traduit en langage sgml, utilise par le
  Linux Documentation Project.  Ce langage peut etre 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 edition papier ; de
  plus, le document contient des references 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teess ddee llaa vveerrssiioonn 11..22

  Cette   revision   est   plutot   une   augmentation.    Elle   inclut
  principalement des modifications  proposees  par  des  lecteurs,  dont
  l'une est particulierement importante.

  Le   premier   changement   a   ete   suggere   par   Egil   Kvaleberg
  <egil@kvaleberg.no>, qui a signale  la  commande  dump  dans  debugfs.
  Merci encore, Egil.

  Le  second  changement  a ete de signaler l'utilisation de chattr pour
  eviter de supprimer des fichiers importants.   Merci  a  Herman  Suijs
  <H.P.M.Suijs@kub.nl> de l'avoir signale.

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

  11..22..

  OOuu 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  recente de ce document devrait etre
  disponible au format texte  aupres  du  site  du  Linux  Documentation
  Project  <http://sunsite.unc.edu/LDP/>  (et ses miroirs).  La derniere
  version     est     egalement     disponible     sur      ma      page
  <http://pobox.com/~aaronc/> sous divers formats :

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

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

  +o  format   texte  <http://pobox.com/~aaronc/tech/e2-undel/howto.txt>,
     egalement genere automatiquement depuis le source SGML.  Notez  que
     ce  fichier  est  identique  a celui de Sunsite : si vous voulez la
     version texte, vous etes invite a la charger  depuis  votre  miroir
     LDP favori (pour des raisons de rapidite de transfert).

  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 a MS-DOS en
  matiere de recuperation de donnees. Pour MS-DOS (et son batard Windows
  95),  il est generalement tres simple de recuperer un fichier supprime
  : le " systeme d'exploitation " (il faut le dire vite) est  accompagne
  d'un  utilitaire  qui  automatise la procedure. Ce n'est pas le cas de
  Linux.

  Donc... regle numero un (ou premiere directive, si vous preferez) :

       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. D'accord, je ne suis pas le mieux place  pour  le
  dire.  Je me contenterai d'arguer de ma deche (etre etudiant a tout de
  meme ses petits avantages...)  et exhorterai les  utilisateurs  senses
  de Linux de sortir acheter un peripherique 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.   Pour  plus d'information sur le sujet, voir Frisch (1995)
  (voir la section ``Bibliographie et remerciements'').

  En l'absence de sauvegardes, que faire (en fait, meme en  presence  de
  sauvegardes  :  dans le cas de donnees 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 ecriture provoque une demande de
  confirmation explicite de rm avant la destruction  (mais  si  je  veux
  supprimer  recursivement  un  repertoire avec rm -r, j'interromprai le
  programme des la premiere ou deuxieme  demande  de  confirmation  pour
  relancer la commande avec rm -rf).

  Un  bon  truc,  pour  les  fichiers  importants,  est de creer un lien
  physique vers eux dans un repertoire cache. J'ai entendu  parler  d'un
  administrateur     systeme     qui,     periodiquement,     supprimait
  accidentellement /etc/passwd (et par la-meme detruisait  a  moitie  le
  systeme).  Un des remedes 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 completement le  contenu  du
  fichier : si vous dites

         # rm /etc/passwd

  alors

         # ln /.backup/passwd /etc

  permettra de le recuperer. Naturellement, cela ne couvre pas le cas ou
  vous avez ecrase le contenu du fichier par un autre fichier,  donc  de
  toutes facons gardez vos sauvegardes.

  Dans  un  systeme  de  fichiers  ext2,  il  et possible d'utiliser les
  attributs ext2 dans le but de proteger  ses  donnees.   Ces  attributs
  sont  manipules  a 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
  donnees  a un fichier ayant cet attribut, mais pas de le supprimer, et
  le contenu du fichier ne peut pas etre ecrase.  Si un repertoire a cet
  attribut, tous les fichiers et repertoires qu'il contient peuvent etre
  normalement modifies, mais aucun fichier ne peut  etre  supprime.  Cet
  attribut peut etre place en tapant

         $ chattr +a FILE...

  Il existe aussi un attribut " immuable " (_i_m_m_u_t_a_b_l_e), qui ne peut etre
  place ou retire qu'en tant que _r_o_o_t.  Un fichier ou  repertoire  ayant
  cet  attribut  ne peut etre ni mofifie, ni supprime, ni renomme, ni se
  faire ajouter un lien (physique).  Il peut etre place comme suit :

         # chattr +i FILE...

  Ext2fs fournit egalement  l'attribut  "  recuperable  "  (_u_n_d_e_l_e_t_a_b_l_e,
  option  +u  de chattr). Si un fichier ayant cet attribut est supprime,
  mais pas reellemnt reutilise, il est deplace vers un " endroit  sur  "
  afin d'etre supprime plus tard.  Helas, cette fonctionnalite n'est pas
  encore implantee dans les noyaux courants. Vous pouvez  vous  procurer
  des  _p_a_t_c_h_e_s  fournissant la fonctionnalite de destruction reversible,
  consultez

  <http://www.linuxhq.com/>

  si  vous  souhaitez  ajouter  ce  service  a  votre   noyau.    A   ma
  connaissance,   le  plus  recent  _p_a_t_c_h  est  celui  de  Rogier  Wolff
  <R.E.Wolff@BitWizard.nl>, Darren J Moffat  <darren@xarius.demon.co.uk>
  et  Kurt  Huwig <kurt@huwig.de>.  Je precise bien que meme si ce _p_a_t_c_h
  implante cette fonctionnalite, ce n'est pas  a  l'heure  actuelle  une
  reelle  solution  de  recuperation.   Les  fichiers  recuperables sont
  simplement deplaces dans un autre repertoire. Un  demon  devrait  etre
  charge d'y faire periodiquement le menage.

  Certains  defendent  l'idee de faire de rm un alias ou une fonction du
  gestionnaire de commandes qui execute  en  fait  rm  -i  (qui  demande
  confirmation pour _t_o_u_s les fichiers a supprimer).  En effet, certaines
  versions de la distribution Red Hat <http://www.redhat.com/>  le  font
  par  defaut  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 different, ou simplement une autre machine,
  ou votre fonction rm n'existera pas.  Si  vous  vous  attendez  a  une
  confirmation,  il est assez facile d'oublier ou vous etes et specifier
  un peu trop de fichiers a supprimer. De meme, les  divers  scripts  et
  programmes  servant  a  remplacer  rm  sont,  a  mon humble avis, tres
  dangereux.

  Une solution un peu  meilleure  serait  de  commencer  a  utiliser  un
  paquetage   qui   manipulerait  une  destruction  "  recyclable  "  en
  fournissant une commande qui ne s'appellerait pas rm.   Pour  plus  de
  details,  voir  Peek  _e_t _a_l (1993) (voir la section ``Bibliographie et
  remerciements'').

  33..  AA qquueell ttaauuxx ddee rreeccuuppeer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 ??

  Ca depend. Parmi les problemes concernant la recuperation de  fichiers
  dans  un  systeme  d'exploitation  de  haute  qualite, multi-taches et
  multi-utilisateurs comme Linux, il se trouve que vous ne savez  jamais
  quand  quelqu'un  veut  ecrire  sur  le disque. Donc, quand le systeme
  d'exploitation recoit l'ordre de  supprimer  un  fichier,  il  suppose
  libres  les  blocs  utilises  par  ce  fichier  au moment d'allouer de
  nouveau de la place pour un nouveau fichier (c'est un exemple  typique
  d'un  principe  general  de  Linux  :  le noyau et les outils associes
  supposent que les utilisateurs ne sont pas des  idiots).  En  general,
  plus  votre  machine  est  utilisee,  moins  vous  avez  de chances de
  recuperer vos fichiers avec succes.

  De plus, la fragmentation du  disque  peut  affecter  la  facilite  de
  recuperation.  Si  la  partition  contenant les fichiers supprimes est
  tres fragmentee, vous avez peu de chances de pouvoir lire  un  fichier
  entier.

  Si  votre  machine,  comme  la  mienne,  est effectivement une station
  destinee a un seul utilisateur (la  mienne  n'a  meme  pas  encore  de
  connexion   reseau   ;  peut-etre  l'annee  prochaine),  et  que  vous
  n'utilisiez  pas  intensivement  le  disque  au  moment  fatal  de  la
  destruction,  j'attendrais  un  taux  de recuperation du meme ordre de
  grandeur que decrit precedemment.  J'ai  recupere  presque  94  %  des
  fichiers, intacts (et il s'agissait de fichiers binaires, notez bien).
  Je dirais qu'au-dela de 80 %, vous pouvez etre plutot 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reeccuuppeerree uunn ffiicchhiieerr ??

  La  procedure  consiste principalement en la recherche de donnees dans
  le peripherique de la partition en mode caractere, et le  fait  de  la
  rendre  a  nouveau  visible  par  le  systeme  d'exploitation.  Il y a
  principalement deux manieres de le faire  :  la  premiere  consiste  a
  modifier  le systeme de fichier existant de telle facon que les inodes
  supprimees aient leur indicateur " supprime " retire, et  esperer  que
  les  donnees retombent comme par magie a leur place.  L'autre methode,
  plus sure mais plus lente,  est  de  rechercher  ou  se  trouvent  les
  donnees dans la partition et de les ecrire dans un nouveau fichier.

  Vous  devez suivre plusieurs etapes avant de commencer votre tentative
  de  recuperation  ;  voir  les  sections  ``Demonter  le  systeme   de
  fichiers'',   ``Preparer  la  modification  directe  des  inodes''  et
  ``Preparer l'ecriture a un autre endroit'' pour plus de details.  Pour
  decouvrir comment recuperer reellement vos fichiers, voir les sections
  ``Trouver  les  inodes  supprimes'',  ``Obenir  des  details  sur  les
  inodes'',  ``Recuperer des blocs de donnees'' et ``Modifier les inodes
  directement''.

  55..  DDeemmoonntteerr llee ssyysstteemmee ddee ffiicchhiieerrss

  Quelle que soit la methode que vous  choisissiez,  la  premiere  etape
  consiste  a  demonter  le  systeme  de fichiers contenant les fichiers
  supprimes.  Je vous conseille fortement de  refrener  toute  envie  de
  bricoler un systeme de fichiers monte. Cette etape doit etre effectuee
  _l_e _p_l_u_s _t_o_t _p_o_s_s_i_b_l_e, des que vous avez realise que les fichiers  sont
  supprimes.

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

         # umount /usr

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

         # mount -o ro,remount /usr

  Si les fichiers supprimes  etaient  dans  la  partition  racine,  vous
  devrez  ajouter  une  option  -n,  afin  d'empecher que l'operation de
  montage ne declenche une ecriture dans /etc/mtab :

         # mount -n -o ro,remount /

  Independamment de tout cela, il est  possible  qu'un  autre  processus
  utilise  a  ce moment-la ce systeme de fichier (ce qui fera echouer 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 a tout processus utilisant un fichier ou
  point de montage donne : c'est fuser. Pour la partition /usr,  essayez
  ceci :
         # fuser -v -m /usr

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

         # fuser -k -v -m /usr

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

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

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

  66..  PPrreep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 ca. Je ne pense vraiment  pas  qu'il  soit
  raisonnable  d'esperer  un  resultat  en  jouant  avec  un  systeme de
  fichiers a un si bas niveau. Du reste, vous ne  pourrez  recuperer  de
  facon  fiable  que  les  12 premiers blocs de chaque fichier. Donc, si
  vous avez des fichiers longs a recuperer, vous devrez de  toute  facon
  utiliser  l'autre  methode  (mais lisez tout de meme 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  maniere,  je  vous
  conseille de copier les donnees de la partition en mode caractere dans
  une autre partition, puis monter le tout en utilisant le  peripherique
  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

  Ceci  necessite  une  version  recente  de  mount (de toute facon vous
  devriez vous procurer au moins la version 2.6, car toutes les versions
  precedentes  ont un trou de securite important qui autorise l'acces en
  _r_o_o_t a n'importe quel manant.  Les principales distributions, c'est-a-
  dire  Debian, Red Hat et Slackware ont toutes ete mises a jour avec la
  version 2.6 de mount).

  Le but de la manoeuvre est que, quand vous aurez  entierement  detruit
  le  systeme  de  fichiers (ce que vous ferez tres probablement), il ne
  vous restera plus qu'a  copier  la  partition  dans  l'autre  sens  et
  repartir a nouveau.

  77..  PPrreeppaarreerr ll''eeccrriittuurree aa 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.
  Experons-le, votre systeme a  plusieurs  partitions  :  peut-etre  une
  racine,  une  /usr, et une /home. Avec tout ce choix, aucun probleme :
  creez simplement un nouveau repertoire dans l'une d'entre elles.

  Si vous n'avez qu'une partition racine dans laquelle vous fourrez tout
  (comme  moi,  du  moins  tant  que  je  peux  pas  faire autrement que
  repartitionner), ca risque d'etre un  poil  plus  delicat.   Peut-etre
  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-etre  en
  module  ?  Pour utiliser le _r_a_m_d_i_s_k (en supposant que votre noyau soit
  plus recent que 1.3.48), tapez la commande suivante :

         # 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 creer 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 pour charger
  et decharger automatiquement les modules du noyau, alors  ne  demontez
  pas  le  _r_a_m_d_i_s_k  tant  que  vous n'avez copie tous les fichiers qu'il
  contient sur un support non  volatile.   Une  fois  que  vous  l'aurez
  demonte,  kerneld  suppose  qu'il  peut  decharger le module (apres la
  periode d'attente habituelle), et, des qu'il l'a fait, la memoire  est
  reutilisee   par   d'autres   elements  du  noyau,  causant  la  perte
  irremediable des heures de travail que vous aurez passees a  recuperer
  soigneusement vos donnees.

  Si  vous  avez  n'importe lequel des nouveaux peripheriques du style "
  super-disquettes ", il s'agit probablement d'un 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  donnees  necessaires  en   plein   milieu   du
  peripherique  contenant  la  partition.  A  la rigueur, dd pourrait le
  faire, mais pour lire a partir de, disons, 600 Mo dans  une  partition
  de  800  Mo, dd tient a lire les 600 premiers megaoctets, quitte a les
  ignorer, et il va y passer un  temps  non  negligeable.   Pour  eviter
  cela,  j'ai ecrit 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.0.tar.gz>,  et  il   va   sans
  tarder        trouver        sa        voie        vers        Sunsite
  <http://sunsite.unc.edu/pub/Linux/utils/disk-management/>   (et    ses
  miroirs).  Si  vous  souhaitez  utiliser cette methode, la suite de ce
  mini-HOWTO suppose que vous avez fsgrab.

  Si aucun des fichiers que vous voulez recuperer n'occupe  plus  de  12
  blocs  (ou  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 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 fonctionne
  pour  moi,  je  ne  puis  prendre  aucune   responsabilite   sur   son
  comportement.  C'etait  vraiment  une  bidouille  rapide  et sale pour
  arriver a mes fins. Pour plus de details 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 (c'est la GPL, la licence publique generale 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meess

  L'etape suivante consiste a demander au systeme  de  fichiers  quelles
  inodes  ont  ete  recemment  liberes.  C'est une tache que vous pouvez
  accomplir avec debugfs. Lancez debugfs avec le nom du peripherique sur
  lequel le systeme de fichiers reside :

         # debugfs /dev/hda5

  Si  vous souhaitez modifier les inodes directement, ajoutez une option
  -w de maniere a activer l'ecriture sur le systeme de fichiers :

         # debugfs -w /dev/hda5

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

         debugfs:  lsdel

  Apres  moult  grincements  et gemissements du disque, une longue liste
  est envoyee par un _p_i_p_e a 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 resultat. Sinon, vous devrez vous arranger pour envoyer la
  sortie ailleurs. Essayez ceci :

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

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

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

  99..  OObbtteenniirr ddeess ddeet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  details  sur  un  inode.
  Utilisez  la  commande  pour  chacun  des  inodes  de  votre  liste  a
  recuperer. Par exemple, si vous  etes  interesse  par  l'inode  numero
  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  a  recuperer, vous souhaiterez
  automatiser tout cela. En suposant que  votre  liste  (d'apres  lsdel)
  d'inodes a recuperer est dans lsdel.out, essayez ceci :

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

  Ce nouveau fichier inodes contient uniquement les numeros des inodes a
  recuperer, a raison d'un par ligne. On le sauvegarde  parce  qu'il  va
  nous etre surement tres utile par la suite. Il ne vous reste plus qu'a
  taper :

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

  et stats contient la sortie de toutes les commandes stat.

  1100..  RReeccuuppeerreerr lleess bbllooccss ddee ddoonnnneeeess

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

  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  numeros  de
  blocs  ou  sont situees toutes ses donnees sont ecrites dans l'inode :
  vous pouvez les lire directement sur la sortie de stat correspondant a
  l'inode.  De  surcroit,  debugfs  a  une commande qui automatise cette
  tache. Pour reprendre l'exemple precedent :

           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  a debugfs d'ecrire le fichier dans un nouvel endroit,
  comme par exemple /mnt/recovered.000 :

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

  Bien sur, on peut faire ca 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 dechet a
  la fin de /mnt/recovered.000, mais ce n'est  pas  tres  important.  Si
  vous  voulez  vous  en  debarrasser,  la methode 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  sur,  il  est  possible  qu'un ou plusieurs blocs ou etait ecrit
  votre fichier aient ete ecrases. Si c'est le cas, pas de chance  :  le
  bloc  est mort et enterre (rendez-vous compte, si seulement vous aviez
  demonte plus tot !).

  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 problemes apparaissent lorsque le fichier tient  sur  plus  de  12
  blocs  de  donnees. Ici, il vaut mieux en savoir un peu sur la maniere
  dont les systemes de fichiers Unix sont structures.   Les  donnees  du
  fichier  sont  stockees dans des unites appelees " blocs ".  Ces blocs
  peuvent etre numerotes sequentiellement. Un fichier a egalement  un  "
  inode  ",  ou  sont  placees des informations telles que proprietaire,
  permissions ou type.  Comme  les  blocs,  les  inodes  sont  numerotes
  sequentiellement,  bien que la sequence soit differente. Une entree de
  repertoire consiste en un nom de fichier associe a un numero  d'inode.

  Mais,  si  on  en restait la, le noyau ne saurait toujours pas trouver
  les donnees correspondant a une entree de repertoire.   Ainsi  l'inode
  indique  egalement  l'endroit  ou  se trouvent les blocs de donnees du
  fichier, comme suit :

  +o  Les  numeros  de  blocs  des  12  premiers  blocs   sont   indiques
     directement dans l'inode ; on les appelle parfois _b_l_o_c_s _d_i_r_e_c_t_s.

  +o  L'inode  contient  le  numero  de bloc d'un _b_l_o_c _i_n_d_i_r_e_c_t.  Un bloc
     indirect contient les numeros de  bloc  de  256  blocs  de  donnees
     additionnels.

  +o  L'inode  contient  le numero 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 numeros de bloc  de  blocs
     indirects supplementaires.

  +o  L'inode  contient  le numero 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 numeros  de  bloc  de  256
     blocs doublement indirects supplementaires.

  Relisez  bien  tout  ca  :  je  sais  que  c'est complique, mais c'est
  important, aussi.

  Maintenant, l'implantation actuelle du noyau (certainement pour toutes
  les  versions jusqu'a la 2.0.30) annule 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'etes pas garanti de pouvoir retrouver les numeros de tous les  blocs
  dont vous avez besoin (sans parler de leur contenu).

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

     00 aa 1122
        les  numeros  de  bloc  sont indiques dans l'inode, comme decrit
        precedemment ;

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

     226699 aa 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  repetitions de : un bloc indirect
        (inutile) et 256 blocs de donnees ;

     6655880055 oouu pplluuss
        la disposition des 65804 premiers blocs est identique a  ce  qui
        est  decrit  di-dessus.  Suivent  un  bloc  triplement  indirect
        (inutile)  et  256  repetitions  d'une  sequence  "   doublement
        indirect  ". Chaque sequence doublement indirecte consiste en un
        bloc doublement indirect (inutile), suivi de 256 repetitions  de
        : un bloc indirect (inutile) et 256 blocs de donnees.

  Bien  entendu,  meme  si  ces  blocs  sont  supposes corrects, rien ne
  garantit que les donnees qu'ils contiennent sont intactes.   De  plus,
  plus le fichier est long, moins vous avez de chances qu'il ait pu etre
  ecrit dans le systeme de fichiers sans fragmentation raisonnable (sauf
  dans certaines circonstances particulieres).

  Notez  que  j'ai  suppose  depuis le debut que vos blocs occupaient la
  taille de 1024 octets, c'est-a-dire la valeur standard.  Si vos  blocs
  sont plus grands, une partie des nombres ecrits plus haut doivent etre
  changes. Typiquement, puisque chaque numero de bloc occupe  4  octets,
  le  nombre  de  numeros  de  bloc pouvant etre places dans chaque bloc
  indirect est taille_du_bloc/4.  Donc, chaque fois que  le  nombre  256
  apparait   dans   la   dicussion   qui   precede,   remplacez-le   par
  taille_du_bloc/4. Les limitations " nombre de blocs requis  "  devront
  egalement etre modifiees.

  Examinons un exemple de recuperation 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
  fragmente : de facon evidente,  les  12  premiers  blocs  listes  dans
  l'inode  (qui  sont  tous  des  blocs de donnees) sont contigus.  Nous
  pouvons donc commencer par recuperer ces blocs :

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

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

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

  Le dernier bloc liste dans l'inode est le 8583. Notez que ca ressemble
  toujours bien a un fichier contigu : le numero  du  dernier  bloc  que
  nous  ayons ecrit etait le 8582, donc 8327 + 255.  Ce bloc 8583 est un
  bloc doublement indirect, que nous pouvons ignorer. Il est  suivi  par
  jusqu'a 256 repetitions d'un bloc indirect (ignore) suivi de 256 blocs
  de donnees. Apres un petit calcul mental, on en deduit  les  commandes
  suivantes.   Remarquez qu'on saute le bloc doublement indirect 8583 et
  le bloc indirect 8584,  qui  suivent  immediatement  (esperons-le)  et
  qu'on commence directement a lire les donnees 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 ecrit depuis le debut 12 + (7 *
  256) blocs, c'est-a-dire 1804. La commande " stat  "  nous  a  indique
  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
  reellement 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  donnees  ecrit portait le numero 10125. De la meme facon que
  depuis le debut, on saute un bloc indirect (numero 10126)  ;  on  peut
  alors ecrire 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 ete
  recupere avec succes.

  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 methode est apparemment beaucoup plus facile.  Cependant,  comme
  souligne plus haut, elle ne peut pas venir a bout de fichiers occupant
  plus de 12 blocs.

  Pour chaque inode que vous voulez recuperer, vous devez mettre a 1  le
  nombre  de  liens, et a 0 la date de suppression.  Cela peut etre fait
  grace a 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-a-dire  que  je  mets a 0 la date de suppression et le nombre de
  liens a 1, puis j'envoie juste  un  retour  chariot  pour  chacun  des
  autres  champs.  D'accord,  ce  n'est  pas  tres  souple  si vous avez
  beaucoup de fichiers a recuperer, mais je pense que vous pourrez faire
  face.  Si  vous  vouliez  du velours, il fallait utiliser un " systeme
  d'exploitation " graphique avec une jolie " corbeille ".

  A propos, le texte de sortie de mi  indique  un  champ  "  creation  "
  (_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  systeme  de  fichiers  Unix,  vous  ne  pouvez  pas
  determiner quand un fichier a ete cree. Le champ st_ctime d'une struct
  stat fait reference a la date de modification de l'inode (_i_n_o_d_e _c_h_a_n_g_e
  _t_i_m_e),  c'est-a-dire  la derniere fois qu'un quelconque des details de
  l'inode a ete change. Si finit la lessons d'huy.

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

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

         # e2fsck -f /dev/hda5

  L'idee est que chacun des fichiers supprimes a ete litteralement " de-
  supprime  ",  mais  qu'aucun  d'entre  eux  n'apparait  en  entree  de
  repertoire. Le programme e2fsck peut  le  detecter,  et  ajoutera  une
  entree dans le repertoire /lost+found du systeme de fichiers (Donc, si
  la partition est normalement  montee  dans  /usr,  les  fichiers  vont
  apparaitre  dans  /usr/lost+found).  Tout  ce qui reste a faire est de
  redonner son nom a chaque fichier d'apres son contenu, et le  remettre
  a sa place dans l'arborescence du systeme de fichiers.

  Quand   vous   lancerez   e2fsck,   vous   obtiendrez   des   messages
  d'information, ainsi que  des  questions  a  propos  des  problemes  a
  reparer.   Repondez   oui   (_y_e_s)   partout  ou  vous  voyez  _`_s_u_m_m_a_r_y
  _i_n_f_o_r_m_a_t_i_o_n_' ou a chaque reference aux inodes que vous avez modifiees.
  Tout  le reste vous regarde, bien qu'il soit en general une bonne idee
  de repondre oui a toutes les questions.   Lorsque  e2fsck  a  termine,
  vous pouvez remonter le systeme de fichiers.

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

         debugfs:  link <148003> toto.txt

  Ceci cree un fichier appele toto.txt dans ce que debugfs suppose  etre
  le  repertoire courant ; toto.txt sera votre fichier. Vous aurez quand
  meme 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 deja le cas. Les noyaux de la serie
  en cours de developpement 2.1.x ne  mettent  plus  a  zero  les  blocs
  indirects  depuis  plus  de  six mois.  Debut decembre 1996, il y a eu
  quelques discussions dans  la  liste  de  distribution  (_m_a_i_l_i_n_g_-_l_i_s_t)
  linux-kernel  en  faveur de la production d'un nouveau noyau 2.0.x qui
  laisserait egalement les blocs intacts  apres  suppression.  Bien  que
  cela  n'ait  pas  encore  ete fait, du moins jusqu'a la pre-version du
  noyau 2.0.31, je subodore que c'est faisable. Aussitot  que  Linus  et
  les autres bricoleurs du noyau seront venus a bout de cette limitation
  dans les noyaux stables, bon nombre  de  mes  objections  au  fait  de
  modifier  les inodes a la main disparaitront. Aux dernieres nouvelles,
  cela devrait arriver dans les  noyaux  de  la  serie  2.2.x,  lesquels
  (d'apres  l'echelonnement  historique  des  distributions precedentes)
  devraient arriver quelque part dans le premier quart de  1998.   Quand
  cette  verrue  aura ete soignee, il sera egalement possible d'utiliser
  la commande dump de debugfs sur des fichiers longs.

  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. Helas, je crains qu'ils souffrent du meme probleme
  que la technique de  modifcation  manuelle  des  inodes  :  les  blocs
  indirects  sont  irrecuperables.  Cependant,  selon la probabilite que
  cela ne soit plus un probleme d'ici peu, ca vaut surement le  coup  de
  chercher ces programmes maintenant.

  Quelqu'un,  sur  le  _n_e_t, a mentionne lde de Scott Heavner.  Pour etre
  honnete, je ne le recommanderais pas en tant  qu'outil  destine  a  la
  recuperation de fichiers. C'est plutot un debugfs plein ecran qu'autre
  chose, bien qu'il ait egalement certaines fonctionnalites  telles  que
  la  capacite  de  parcourir  le systeme pour trouver certains types ou
  certains contenus de  fichiers.   Il  fonctionne  egalement  avec  les
  systemes de fichiers xia (il y a vraiment quelqu'un qui utilise encore
  ca ?) et minix, ce qui a mon avis est un atout majeur  en  ce  moment.
  La      version      2.3.4     est     disponible     chez     Sunsite
  <ftp://sunsite.unc.edu/pub/Linux/system/Filesystems/lde-2.3.4.tar.gz>
  et  ses  miroirs (bien qu'il soit possible qu'une version plus recente
  existe ; j'ai trouve celle-ci dans un cederom  d'archive  vieux  de  8
  mois).  lde  possede  une  documentation  sur les concepts de base des
  systemes de fichiers  particulierement  utile,  ainsi  qu'un  document
  expliquant   comment   l'utiliser   afin  de  recuperer  des  fichiers
  supprimes. Bien que ne l'ayant pas utilise, je  suppose  meilleure  ma
  propre methode.

  Il  semble  que  le programme qui marche _v_r_a_i_m_e_n_t soit le GNU Midnight
  Commander, mc. C'est un  gestionnaire  de  fichiers  en  plein  ecran,
  inspire   autant  que  je  le  sache  d'un  certain  programme  MS-DOS
  couramment designe sous le nom de " nc ".  mc supporte la souris  dans
  la console Linux et dans un xterm, et fournit des systemes de fichiers
  virtuels qui permettent des trucs du genre de  se  deplacer  dans  une
  archive  Tar.  Parmi  ses  systemes de fichiers virtuels, il en est un
  concernant la recuperation sous Ext2. Tout ca semble  tres  commode  a
  manipuler,  mais je dois avouer que que je ne l'ai jamais utilise moi-
  meme  --  je  prefere  les  bonnes  commandes  _s_h_e_l_l   a   l'ancienne.
  Apparemment  il  faut  configurer  le  programme avec l'option --with-
  ext2undel  ;  vous  aurez  egalement  besoin  des   bibliotheques   de
  developpement et des fichiers d'en-tete (_i_n_c_l_u_d_e) qui viennent avec le
  paquetage e2fsprogs.  J'en deduis qu'une fois  que  le  programme  est
  compile,  vous  pouvez  y  taper cd undel:/dev/hda5/, et obtenir, sous
  forme de contenu de repertoire, le catalogue des fichiers supprimes.

  La derniere version stable est probablement  la  4.0;  Comme  pour  le
  noyau lui-meme, les versions de developpement ne sont _p_a_s recommandees
  aux utilisateurs non specialistes.  La liste des nombreux (plus de 70)
  sites   est   disponible   sur   la   page  de  Midnight  Commander  4
  <http://mc.blackdown.org/mc4/>, ou vous pouvez  essayer  le  site  ftp
  officiel  <ftp://ftp.nuclecu.unam.mx/linux/local/mc-4.0.tar.gz>  (qui,
  si j'ai bonne memoire, est plutot lent).

  1144..

  AAcchheevvee dd''iimmpprriimmeerr......

  J'ai l'intention de  produire  des  mises  a  jour  regulieres  de  ce
  document,  tant  que  j'aurai  a la fois suffisamment de temps pour le
  faire et quelque chose d'interessant a dire. Ceci signifie que je suis
  avide  de  commentaires de la part de mes lecteurs. Ma redaction peut-
  elle etre plus  claire  ?  Pouvez-vous  penser  a  quelque  chose  qui
  pourrait  rendre  l'affaire  plus simple ? Existe-t-il un nouvel outil
  qui puisse faire tout cela automatiquement ? Qui a bien pu tuer JFK  ?
  Et  qui  est  le  proprietaire  de la Fiat Uno noire du pont de l'Alma
  (NdT) ?

  Quoi qu'il en soit : si vous avez quoi que ce soit a dire, a propos de
  ce document ou de tout autre sujet, envoyez un mot a :

  <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_'_e_t_a_i_s
       _h_i_s_s_e _s_u_r _d_e_s _e_p_a_u_l_e_s _d_e _g_e_a_n_t_s (Isaac Newton)

  Une grande partie de ce mini-Howto est derivee d'un article poste  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  autorise  a
  reprendre ses idees dans ce mini-Howto.

  Quelques references bibliographiques :

  +o  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.

  +o  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.

  +o  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  deposees  sont  la  propriete  de  leurs auteurs
  respectifs. Specifiquement :

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

  +o  _U_N_I_X    est    une    marque    deposee    de    _t_h_e   _O_p_e_n   _G_r_o_u_p
     _<_h_t_t_p_:_/_/_w_w_w_._o_p_e_n_._o_r_g_/>.

  +o  le statut de marque deposee du nom _L_i_n_u_x est actuellement  conteste
     par la justice. Un certain Walter R. Della Croce a fait un pretendu
     faux  enregistrement  de  marque  deposee  du  terme.   Pour   plus
     d'information  sur  le probleme de Linux comme marque deposee, voir
     le the Linux Mall <http://www.linuxmall.com/announce/>.

  Ce document est Copyright (c) 1997 Aaron Crane <aaronc@pobox.com>.  Il
  peut etre librement et entierement redistribue a condition d'y inclure
  toujours la totalite de cette note de copyright, mais ne peut pas etre
  modifie  sans l'autorisation, soit de son auteur, soit du coordinateur
  du Linux Documentation Project.  Une derogation est cependant accordee
  dans  le cas de la copie de courts extraits sans modification pour des
  revues ou une citation ; dans ces circonstances, les sections  peuvent
  etre  reproduites  accompagnees  d'une  citation  appropriee 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    Greg    Hankins
  <gregh@sunsite.unc.edu>.

