/usr/share/doc/HOWTO/fr-html/Ext2fs-Undeletion.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for HTML5 for Linux version 5.2.0">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.72">
<title>Linux Ext2fs Undeletion mini-HOWTO</title>
</head>
<body>
<h1>Linux Ext2fs Undeletion mini-HOWTO</h1>
<h2>Aaron Crane, <code><a href=
"mailto:aaronc@pobox.com">aaronc@pobox.com</a></code></h2>
v1.3, 2 Février 1999
<hr>
<em>(Adaptation française par <a href=
"mailto:miodrag@multimania.com">Miodrag Vallat</a>, anciennement
par <a href="mailto:canet@labri.u-bordeaux.fr">Géraud Canet</a> et
<a href="mailto:regnault@axpcalc.crpp.u-bordeaux.fr">Sylviane
Regnault</a>). Imaginez un peu. Vous avez passé les trois derniers
jours sans dormir, sans manger, sans même prendre une douche. Votre
bidouillomanie compulsive a enfin porté ses fruits&nbsp;: 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 <code>rm * ~</code>. Et, trop tard, vous
remarquez l'espace en trop. Vous avez détruit votre <em>oeuvre
maîtresse</em>&nbsp;! Mais, heureusement, vous avez de l'aide à
portée de main. Ce document présente une discussion de la
récupération de fichiers supprimés depuis le Second système de
fichiers étendu ext2fs. Espérez, peut-être pourrez-vous distribuer
votre programme malgré tout...</em>
<hr>
<h2><a name="s1">1. Introduction</a></h2>
<p>Ce mini-HOWTO tente de fournir un certain nombre de conseils
dans le but de récupérer des fichiers supprimés depuis un système
de fichiers ext2fs. Il contient également une petite discussion sur
les manières de commencer par éviter de supprimer des fichiers.</p>
<p>Mon but est naturellement d'en faire une référence utile à tous
ceux qui ont eu un, disons... accident avec <code>rm</code>&nbsp;;
mais cependant je souhaite que les gens le lisent de toute façon.
On ne sait jamais&nbsp;: un jour, les renseignements donnés ici
pourraient vous sauver la couenne.</p>
<p>La lecture de ce texte suppose un minimum de connaissances sur
les systèmes de fichiers Unix&nbsp;; je me suis cependant efforcé
de le rendre accessible à la plupart des utilisateurs de Linux. Si
vous êtes un grand débutant, je crains que la récupération de
fichiers sous Linux <em>exige</em> certaines connaissances
techniques, ainsi que de la persévérance, au moins dans l'état
actuel des choses.</p>
<p>Il vous sera impossible de récupérer des fichiers supprimés
depuis un système de fichiers ext2 sans au moins un accès en
lecture au périphérique (fichier spécial) sur lequel le fichier
était placé. En général, cela signifie que vous devez être
<em>root</em>, mais plusieurs distributions (comme <a href=
"http://www.debian.org/">Debian GNU/Linux</a>) disposent d'un
groupe <code>disk</code> dont les membres ont ces accès. Vous aurez
également besoin de la commande <code>debugfs</code>, du paquetage
<code>e2fsprogs</code>, qui devrait avoir été installé par votre
distribution.</p>
<p>Pourquoi ai-je écrit ceci&nbsp;? Principalement par expérience
personnelle, souvenir du désastre d'un <code>rm -r</code>
particulièrement insensé en tant que <em>root</em>. J'ai supprimé
97 fichiers JPEG dont j'avais besoin et que je ne pouvais
certainement pas récupérer par ailleurs. Suivant quelques conseils
(voir la section <a href="#sec-credits">Remerciements et
bibliographie</a>) et en persévérant beaucoup, j'ai récupéré 91
fichiers intacts. Je suis parvenu à en retrouver, au moins en
partie, cinq autres (suffisamment pour voir quelle était l'image
représentée par chacun). Une seule n'était pas affichable, et même
pour celle-là, je suis certain de n'avoir pas perdu plus de 1024
octets (mais hélas depuis le début du fichier&nbsp;; sachant que je
ne connais rien du format de fichier JFIF j'ai vraiment fait ce que
j'ai pu).</p>
<p>Je discuterai plus bas du taux de récupération que vous pouvez
espérer pour les fichiers supprimés.</p>
<h2><a name="ss1.1">1.1 Historique des révisions</a></h2>
<p>Les révisions de ce document (en version anglaise, NdT)
délivrées au public, ainsi que leurs dates de publication, sont les
suivantes&nbsp;:</p>
<ul>
<li>v1.0, 18 janvier 1997&nbsp;;</li>
<li>v1.1, 23 juillet 1997 (voir <a href="#sec-v1.1">Nouveautés
v1.1</a>)&nbsp;;</li>
<li>v1.2, 4 août 1997 (voir <a href="#sec-v1.2">Nouveautés
v1.2</a>)&nbsp;;</li>
<li>v1.3, 2 février 1999 (voir <a href="#sec-v1.3">Nouveautés
v1.3</a>).</li>
</ul>
<h3><a name="sec-v1.1"></a> Nouveautés de la version 1.1</h3>
<p>Quels sont les nouveautés de cette version&nbsp;? Primo, la
réflexion dans l'exemple de la récupération de fichiers a été
corrigée. Merci à tous ceux qui m'ont écrit pour me signaler mon
erreur&nbsp;; cela m'apprendra, je l'espère, à faire plus attention
en inventant des séquences interactives.</p>
<p>Secundo, la discussion sur le modèle de système de fichier Unix
a été récrite afin d'être (espérons-le) plus compréhensible. Je
n'en étais pas entièrement satisfait de prime abord, et d'aucuns se
sont plaints de son manque de clarté.</p>
<p>Tertio, le gros-tas-de-tar-gzip-uu-encodé de <code>fsgrab</code>
au milieu du fichier a été retiré. Le programme est désormais
disponible sur <a href=
"http://pobox.com/~aaronc/tech/fsgrab-1.2.tar.gz">ma page</a> et
sur <a href=
"http://metalab.unc.edu/pub/Linux/utils/file/">Metalab</a> (et ses
miroirs).</p>
<p>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&nbsp;; de plus, le document contient des références
et des liens bien commodes si vous le consultez sur le Web.</p>
<h3><a name="sec-v1.2"></a> Nouveautés de la version 1.2</h3>
<p>Cette révision est plutôt une augmentation. Elle inclut
principalement des modifications proposées par des lecteurs, dont
l'une est particulièrement importante.</p>
<p>Le premier changement a été suggéré par Egil Kvaleberg
<code><a href=
"mailto:egil@kvaleberg.no">egil@kvaleberg.no</a></code>, qui a
signalé la commande <code>dump</code> dans <code>debugfs</code>.
Merci encore, Egil.</p>
<p>Le second changement a été de signaler l'utilisation de
<code>chattr</code> pour éviter de supprimer des fichiers
importants. Merci à Herman Suijs <code><a href=
"mailto:H.P.M.Suijs@kub.nl">H.P.M.Suijs@kub.nl</a></code> de
l'avoir signalé.</p>
<p>Le résumé a été revu. Des URLs ont été ajoutées, qui indiquent
des organisations ou des logiciels. Ajoutez à cela quelques
modifications mineures (dont des corrections de fautes de frappe,
etc.).</p>
<h3><a name="sec-v1.3"></a> Nouveautés de la version 1.3</h3>
<p>Bien qu'il se soit écoulé 17 mois depuis la dernière 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 démodés, comme ceux sur
les versions de noyau et <code>lde</code>, ont été revus. Oh, et
j'ai remplacé `Sunsite' par `Metalab' partout.</p>
<p>Cette version sera probablement la dernière avant la version
2.0, qui sera un vrai HOWTO, du moins je l'espère. J'ai travaillé
sur des changements d'importance qui méritent l'incrémentation du
numéro de version majeure.</p>
<h2><a name="ss1.2">1.2 Où trouver ce document</a></h2>
<p>La version officielle la plus récente de ce document devrait
être disponible au format texte auprès du site du <a href=
"http://metalab.unc.edu/LDP/">Linux Documentation Project</a> (et
ses miroirs). La dernière version est également disponible sur
<a href="http://pobox.com/~aaronc/">ma page</a> sous divers
formats&nbsp;:</p>
<ul>
<li><a href=
"http://pobox.com/~aaronc/tech/e2-undel/howto.sgml">source
SGML</a>, tel que je l'ai écrit&nbsp;;</li>
<li><a href=
"http://pobox.com/~aaronc/tech/e2-undel/html/">HTML</a>, généré
automatiquement depuis le source SGML&nbsp;;</li>
<li><a href=
"http://pobox.com/~aaronc/tech/e2-undel/howto.txt">format
texte</a>, également généré automatiquement depuis le source
SGML.</li>
</ul>
<h2><a name="s2">2. Comment ne pas supprimer de fichiers</a></h2>
<p>Il est vital de se rappeler que Linux n'est pas semblable à
MS-DOS en matière de récupération de données. Pour MS-DOS (et son
bâtard Windows 95), il est généralement très simple de récupérer un
fichier supprimé&nbsp;: le � système d'exploitation � (il faut le
dire vite) est même accompagné d'un utilitaire qui automatise la
procédure. Ce n'est pas le cas de Linux.</p>
<p>Donc... règle numéro un (ou première directive, si vous
préférez)&nbsp;:</p>
<blockquote><b>FAITES DES SAUVEGARDES</b></blockquote>
<p>peu importe comment. Pensez à toutes vos données. Peut-être,
comme moi, conservez-vous plusieurs années 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&nbsp;!&nbsp;-- si un cracker
nettoyait votre disque sans vergogne. Ce n'est pas si
improbable&nbsp;; j'ai correspondu avec un bon nombre de gens
placés dans une telle situation. J'exhorte les utilisateurs sensés
de Linux de sortir acheter un périphérique de sauvegarde, de
planifier leurs sauvegardes dans un emploi du temps digne de ce nom
et de <em>s'y conformer</em>. En ce qui me concerne, je me sers
d'un disque dédié sur une deuxième machine, et régulièrement je
fais un mirroir de mon répertoire personnel par le réseau. Pour
plus d'information sur la planification des sauvegardes, lisez
Frisch (1995) (voir la section <a href="#sec-credits">Bibliographie
et remerciements</a>).</p>
<p>En l'absence de sauvegardes, que faire (en fait, même en
présence de sauvegardes&nbsp;: dans le cas de données importantes,
la ceinture et les bretelles, ce n'est pas du luxe)&nbsp;?</p>
<p>Essayez de donner aux fichiers importants les droits 440 (ou
moins)&nbsp;: ne pas vous laisser les droits en écriture provoque
une demande de confirmation explicite de <code>rm</code> avant la
destruction (mais si je veux supprimer récursivement un répertoire
avec <code>rm -r</code>, j'interromprai le programme dès la
première ou deuxième demande de confirmation pour relancer la
commande avec <code>rm -rf</code>).</p>
<p>Un bon truc, pour les fichiers importants, est de créer un lien
physique vers eux dans un répertoire caché. J'ai entendu parler
d'un administrateur système qui, périodiquement, supprimait
accidentellement <code>/etc/passwd</code> (et par là-même
détruisait à moitié le système). Un des remèdes fut de lancer en
tant que <em>root</em> quelque chose comme&nbsp;:</p>
<blockquote>
<pre><code>
# mkdir /.backup
# ln /etc/passwd /.backup
</code></pre></blockquote>
<p>Il est alors assez difficile de supprimer complètement le
contenu du fichier&nbsp;: si vous dites</p>
<blockquote>
<pre><code>
# rm /etc/passwd
</code></pre></blockquote>
<p>alors</p>
<blockquote>
<pre><code>
# ln /.backup/passwd /etc
</code></pre></blockquote>
<p>permettra de le récupérer. Naturellement, cela ne couvre pas le
cas où vous avez écrasé le contenu du fichier par un autre fichier,
donc de toutes façons gardez vos sauvegardes.</p>
<p>Dans un système de fichiers ext2, il et possible d'utiliser les
attributs ext2 dans le but de protéger ses données. Ces attributs
sont manipulés à l'aide de la commande <code>chattr</code>. Il y a
un attribut � ajout seulement � (<em>append-only</em>)&nbsp;: il
est possible d'ajouter des données à un fichier ayant cet attribut,
mais pas de le supprimer, et le contenu du fichier ne peut pas être
écrasé. Si un répertoire a cet attribut, tous les fichiers et
répertoires qu'il contient peuvent être normalement modifiés, mais
aucun fichier ne peut être supprimé. Cet attribut peut être placé
en tapant</p>
<blockquote>
<pre><code>
$ chattr +a FICHIER...
</code></pre></blockquote>
<p>Il existe aussi un attribut � immuable � (<em>immutable</em>),
qui ne peut être placé ou retiré qu'en tant que <em>root</em>. Un
fichier ou répertoire 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&nbsp;:</p>
<blockquote>
<pre><code>
# chattr +i FICHIER...
</code></pre></blockquote>
<p>Ext2fs fournit également l'attribut � récupérable �
(<em>undeletable</em>, option <code>+u</code> de
<code>chattr</code>). Si un fichier ayant cet attribut est
supprimé, mais pas réellemnt réutilisé, il est déplacé vers un �
endroit sûr � afin d'être supprimé plus tard. Hélas, cette
fonctionnalité n'est pas encore implantée dans les noyaux
courants&nbsp;; et bien que, par la passé, il y ait eu un peu
d'intérêt concernant une implantation éventuelle, elle n'est pas (à
ma connaissance) disponible pour les noyaux actuels.</p>
<p>Certains défendent l'idée de faire de <code>rm</code> un alias
ou une fonction du gestionnaire de commandes qui exécute en fait
<code>rm -i</code> (qui demande confirmation pour <em>tous</em> les
fichiers à supprimer). En effet, certaines versions de la
distribution <a href="http://www.redhat.com/">Red Hat</a> le font
par défaut pour tous les utilisateurs, y compris <em>root</em>. 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
différent, ou simplement une autre machine, où votre fonction
<code>rm</code> n'existera pas. Si vous vous attendez à une
confirmation, il est assez facile d'oublier où vous êtes et
spécifier un peu trop de fichiers à supprimer. De même, les divers
scripts et programmes servant à remplacer <code>rm</code> sont, à
mon humble avis, très dangereux.</p>
<p>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 <code>rm</code>.
Pour plus de détails, voir Peek <i>et al</i> (1993) (voir la
section <a href="#sec-credits">Bibliographie et remerciements</a>).
Cette solution a cependant l'inconvénient d'encourager les
utilisateurs à avoir une attitude nonchalante vis-à-vis de la
destruction, au lieu de l'attitude circonspecte qui est souvent
nécessaire sous Unix.</p>
<h2><a name="s3">3. À quel taux de récupération puis-je
m'attendre&nbsp;?</a></h2>
<p>Ça dépend. Parmi les problèmes concernant la récupération de
fichiers dans un système d'exploitation de haute qualité,
multi-tâches et multi-utilisateurs comme Linux, il se trouve que
vous ne savez jamais quand quelqu'un veut écrire sur le disque.
Donc, quand le système d'exploitation reçoit l'ordre de supprimer
un fichier, il suppose libres les blocs utilisés par ce fichier au
moment d'allouer de nouveau de la place pour un nouveau fichier
(c'est un exemple typique d'un principe général d'Unix&nbsp;: le
noyau et les outils associés supposent que les utilisateurs ne sont
pas des idiots). En général, plus votre machine est utilisée, moins
vous avez de chances de récupérer vos fichiers avec succès.</p>
<p>De plus, la fragmentation du disque peut affecter la facilité de
récupération. Si la partition contenant les fichiers supprimés est
très fragmentée, vous avez peu de chances de pouvoir lire un
fichier entier.</p>
<p>Si votre machine, comme la mienne, est effectivement une station
destinée à un seul utilisateur, et que vous n'utilisiez pas
intensivement le disque au moment fatal de la destruction, je
m'attendrais à un taux de récupération du même ordre de grandeur
que décrit précédemment. J'ai récupéré presque 94 % des fichiers,
intacts (et il s'agissait de fichiers binaires, notez bien). Si
vous obtenez plus de 80 %, vous pouvez être plutôt content de
vous.</p>
<h2><a name="s4">4. Bon, alors comment je récupère un
fichier&nbsp;?</a></h2>
<p>La procédure consiste principalement en la recherche de données
dans le périphérique de la partition en mode caractère, et en le
fait de la rendre à nouveau visible par le système d'exploitation.
Il y a principalement deux manières de le faire&nbsp;: la première
consiste à modifier le système de fichier existant de telle façon
que les inodes supprimés aient leur indicateur � supprimé � retiré,
et espérer que les données retombent comme par magie à leur place.
L'autre méthode, plus sûre mais plus lente, est de rechercher où se
trouvent les données dans la partition et de les écrire dans un
nouveau fichier.</p>
<p>Vous devez suivre plusieurs étapes avant de commencer votre
tentative de récupération&nbsp;; voir les sections <a href=
"#sec-umount">Démonter le système de fichiers</a>, <a href=
"#sec-prep-chg">Préparer la modification directe des inodes</a> et
<a href="#sec-prep-wrt">Préparer l'écriture à un autre endroit</a>
pour plus de détails. Pour découvrir comment récupérer réellement
vos fichiers, voir les sections <a href="#sec-finding">Trouver les
inodes supprimés</a>, <a href="#sec-obtain">Obtenir des détails sur
les inodes</a>, <a href="#sec-recover">Récupérer des blocs de
données</a> et <a href="#sec-modify">Modifier les inodes
directement</a>.</p>
<h2><a name="sec-umount"></a> <a name="s5">5. Démonter le système
de fichiers</a></h2>
<p>Quelle que soit la méthode que vous choisissiez, la première
étape consiste à démonter le système de fichiers contenant les
fichiers supprimés. Je vous conseille fortement de réfréner toute
envie de bricoler un système de fichiers monté. Cette étape doit
être effectuée <em>le plus tôt possible</em>, dès que vous vous
êtes rendu compte que les fichiers sont supprimés.</p>
<p>La méthode la plus simple est la suivante&nbsp;: en supposant
que les fichiers supprimés soient dans la partition
<code>/usr</code>, tapez&nbsp;:</p>
<blockquote>
<pre><code>
# umount /usr
</code></pre></blockquote>
<p>Vous pouvez cependant avoir besoin de garder certaines données
disponibles dans <code>/usr</code>. Dans ce cas, remontez-le en
mode lecture seule&nbsp;:</p>
<blockquote>
<pre><code>
# mount -o ro,remount /usr
</code></pre></blockquote>
<p>Si les fichiers supprimés étaient dans la partition racine, vous
devrez ajouter une option <code>-n</code>, afin d'empêcher que
l'opération de montage ne déclenche une écriture dans
<code>/etc/mtab</code>&nbsp;:</p>
<blockquote>
<pre><code>
# mount -n -o ro,remount /
</code></pre></blockquote>
<p>Indépendamment de tout cela, il est possible qu'un autre
processus utilise à ce moment-là ce système de fichier (ce qui fera
échouer le montage avec une erreur du genre <em>resource
busy</em>). Il y a un programme qui peut envoyer un signal à tout
processus utilisant un fichier ou point de montage donné&nbsp;:
c'est <code>fuser</code>. Pour la partition <code>/usr</code>,
essayez ceci&nbsp;:</p>
<blockquote>
<pre><code>
# fuser -v -m /usr
</code></pre></blockquote>
<p>Cela aura pour effet d'afficher la liste des processus
concernés. En admettant qu'aucun d'entre eux n'est vital, vous
pouvez taper</p>
<blockquote>
<pre><code>
# fuser -k -v -m /usr
</code></pre></blockquote>
<p>afin d'envoyer à chaque processus un <code>SIGKILL</code> (qui
le tuera d'autorité), ou, par exemple,</p>
<blockquote>
<pre><code>
# fuser -k -TERM -v -m /usr
</code></pre></blockquote>
<p>pour envoyer plutôt à chacun un <code>SIGTERM</code> (qui priera
le processus de terminer proprement).</p>
<h2><a name="sec-prep-chg"></a> <a name="s6">6. Préparer la
modification directe des inodes</a></h2>
<p>Mon conseil&nbsp;? Ne faites pas ça. Je ne pense vraiment pas
qu'il soit raisonnable d'espérer un résultat en jouant avec un
système de fichiers à un si bas niveau. Du reste, vous ne pourrez
récupérer de façon fiable que les 12 premiers blocs de chaque
fichier. Donc, si vous avez des fichiers longs à récupérer, vous
devrez de toute façon utiliser l'autre méthode (mais lisez tout de
même la section <a href="#sec-easier">Cela va-t-il se simplifier
dans l'avenir~?</a> pour plus d'information).</p>
<p>Si vous sentez que vous devez le faire de cette manière, je vous
conseille de copier les données de la partition en mode caractère
dans une autre partition, puis monter le tout en utilisant le
périphérique boucle (<em>loopback device</em>)&nbsp;:</p>
<blockquote>
<pre><code>
# cp /dev/hda5 /root/working
# mount -t ext2 -o loop /root/working /mnt
</code></pre></blockquote>
<p>(Notez que les anciennes versions de <code>mount</code> peuvent
avoir des problèmes pour faire cela. Si votre <code>mount</code> ne
fonctionne pas, je vous recommande fortement de vous procurer la
dernière version, ou tout au moins la version 2.7, car plusieurs
versions plus anciennes ont de graves problèmes de sécurité).</p>
<p>Le but de la manoeuvre est que, quand vous aurez entièrement
détruit le système de fichiers (ce que vous ferez très
probablement), il ne vous restera plus qu'à copier la partition
dans l'autre sens et repartir à nouveau.</p>
<h2><a name="sec-prep-wrt"></a> <a name="s7">7. Préparer l'écriture
à un autre endroit</a></h2>
<p>Vous devez vous assurer d'avoir quelque part une partition de
secours. Espérons-le, votre système a plusieurs partitions&nbsp;:
peut-être une racine, une <code>/usr</code>, et une
<code>/home</code>. Avec tout ce choix, aucun problème&nbsp;: créez
simplement un nouveau répertoire dans l'une d'entre elles.</p>
<p>Si vous n'avez qu'une partition racine dans laquelle vous
fourrez tout, ça risque d'être un poil plus délicat. Peut-être
avez-vous une partition MS-DOS ou Windows que vous pourriez
utiliser&nbsp;? Ou vous avez le gestionnaire <em>ramdisk</em> dans
votre noyau, peut-être en module&nbsp;? Pour utiliser le
<em>ramdisk</em> (en supposant que votre noyau soit plus récent que
1.3.48), tapez les commandes suivantes&nbsp;:</p>
<blockquote>
<pre><code>
# dd if=/dev/zero of=/dev/ram0 bs=1k count=2048
# mke2fs -v -m 0 /dev/ram0 2048
# mount -t ext2 /dev/ram0 /mnt
</code></pre></blockquote>
<p>Cela a pour effet de créer un volume <em>ramdisk</em> de 2 Mo,
et de le monter en <code>/mnt</code>.</p>
<p>Un petit mot d'avertissement&nbsp;: si vous utilisez
<code>kerneld</code> (ou son remplaçant <code>kmod</code> avec les
noyaux 2.2.x et les derniers 2.1.x) pour charger et décharger
automatiquement les modules du noyau, alors ne démontez pas le
<em>ramdisk</em> tant que vous n'avez pas copié tous les fichiers
qu'il contient sur un support non volatile. Une fois que vous
l'aurez démonté, <code>kerneld</code> suppose qu'il peut décharger
le module (après la période d'attente habituelle), et, dès qu'il
l'a fait, la mémoire est réutilisée par d'autres éléments du noyau,
causant la perte irrémédiable des heures de travail que vous aurez
passées à récupérer soigneusement vos données.</p>
<p>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.</p>
<p>Une autre chose dont vous devriez avoir besoin est un programme
capable de lire les données nécessaires en plein milieu du
périphérique contenant la partition. À la rigueur, <code>dd</code>
pourrait le faire, mais pour lire à partir de, disons, 600 Mo dans
une partition de 800 Mo, <code>dd</code> tient à lire les 600
premiers mégaoctets, quitte à les ignorer, et il va y passer un
temps non négligeable, même 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 <code>fsgrab</code>&nbsp;;
vous pouvez trouver le paquetage des sources sur <a href=
"http://pobox.com/~aaronc/tech/fsgrab-1.2.tar.gz">ma page</a>, ou
sur <a href=
"http://metalab.unc.edu/pub/Linux/utils/file/">Metalab</a> (et ses
miroirs). Si vous souhaitez utiliser cette méthode, la suite de ce
mini-HOWTO suppose que vous avez <code>fsgrab</code>.</p>
<p>Si aucun des fichiers que vous voulez récupérer n'occupe plus de
12 blocs (où un bloc occupe habituellement un kilooctet), alors
vous n'aurez pas besoin de <code>fsgrab</code>.</p>
<p>Si vous avez besoin de <code>fsgrab</code> mais n'en voulez pas,
il est fort simple de traduire une ligne de commande avec
<code>fsgrab</code> en une avec <code>dd</code>. Si on a</p>
<blockquote><code>fsgrab -c <em>count</em> -s <em>skip</em>
<em>device</em></code></blockquote>
<p>alors la commande <code>dd</code> correpondante (et généralement
beaucoup plus lente) est</p>
<blockquote><code>dd bs=1k if=<em>device</em> count=<em>count</em>
skip=<em>skip</em></code></blockquote>
<p>Je dois vous avertir que, bien que <code>fsgrab</code> 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 détails sur
l'absence de garantie, consultez la section <em>No Warranty</em>
dans le fichier <code>COPYING</code> inclus dans la distribution
(li s'agit de la GPL, la licence publique générale GNU).</p>
<h2><a name="sec-finding"></a> <a name="s8">8. Trouver les inodes
supprimés</a></h2>
<p>L'étape suivante consiste à demander au système de fichiers
quels inodes ont été récemment libérés. C'est une tâche que vous
pouvez accomplir avec <code>debugfs</code>. Lancez
<code>debugfs</code> avec le nom du périphérique sur lequel le
système de fichiers réside&nbsp;:</p>
<blockquote>
<pre><code>
# debugfs /dev/hda5
</code></pre></blockquote>
<p>Si vous souhaitez modifier les inodes directement, ajoutez une
option <code>-w</code> de manière à activer l'écriture sur le
système de fichiers&nbsp;:</p>
<blockquote>
<pre><code>
# debugfs -w /dev/hda5
</code></pre></blockquote>
<p>La commande <code>debugfs</code> permettant de trouver les
inodes détruits est <code>lsdel</code>. Donc, tapez la commande
suivante à l'invite&nbsp;:</p>
<blockquote>
<pre><code>
debugfs:  lsdel
</code></pre></blockquote>
<p>Après moult grincements et gémissements du disque, une longue
liste est envoyée par un <em>pipe</em> à votre <em>pager</em>
favori (la valeur de <code>$PAGER</code>). Maintenant vous aurez
envie d'en sauver une copie autre part. Si vous avez
<code>less</code>, vous pouvez taper <code>-o</code> suivi du nom
du fichier qui devra contenir le résultat. Sinon, vous devrez vous
arranger pour envoyer la sortie ailleurs. Essayez ceci&nbsp;:</p>
<blockquote>
<pre><code>
debugfs:  quit
# echo lsdel | debugfs /dev/hda5 &gt; lsdel.out
</code></pre></blockquote>
<p>Maintenant, d'après la date et l'heure de la suppression, la
taille, le type et les indications numériques des permissions et
propriétaire, vous devez deviner quelles inodes supprimés 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 pêcher dans la
liste.</p>
<p>Je vous suggère, autant que possible, d'imprimer la liste des
inodes que vous voulez récupérer. Cela vous facilitera nettement la
vie.</p>
<h2><a name="sec-obtain"></a> <a name="s9">9. Obtenir des détails
sur les inodes</a></h2>
<p><code>debugfs</code> a une commande <code>stat</code>, qui
imprime des détails sur un inode. Utilisez la commande pour chacun
des inodes de votre liste à récupérer. Par exemple, si vous êtes
intéressé par l'inode numéro 148003, essayez ceci&nbsp;:</p>
<blockquote>
<pre><code>
debugfs:  stat &lt;148003&gt;
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
</code></pre></blockquote>
<p>Si vous avez de nombreux fichiers à récupérer, vous souhaiterez
automatiser tout cela. En suposant que votre liste (d'après
<code>lsdel</code>) d'inodes à récupérer est dans
<code>lsdel.out</code>, essayez ceci&nbsp;:</p>
<blockquote>
<pre><code>
# cut -c1-6 lsdel.out | grep "[0-9]" | tr -d " " &gt; inodes
</code></pre></blockquote>
<p>Ce nouveau fichier <code>inodes</code> contient uniquement les
numéros des inodes à récupérer, à raison d'un par ligne. On le
sauvegarde parce qu'il va nous être sûrement très utile par la
suite. Il ne vous reste plus qu'à taper&nbsp;:</p>
<blockquote>
<pre><code>
# sed 's/^.*$/stat &lt;\0&gt;/' inodes | debugfs /dev/hda5 &gt; stats
</code></pre></blockquote>
<p>et <code>stats</code> contient la sortie de toutes les commandes
<code>stat</code>.</p>
<h2><a name="sec-recover"></a> <a name="s10">10. Récupérer les
blocs de données</a></h2>
<p>Cette partie est soit très facile, soit nettement moins, selon
que les fichiers que vous essayez de récupérer occupent moins ou
plus de 12 blocs.</p>
<h2><a name="ss10.1">10.1 Les fichiers courts</a></h2>
<p>Si le fichier n'occupait pas plus de 12 blocs, alors les numéros
de blocs où sont situées toutes ses données sont écrits dans
l'inode&nbsp;: vous pouvez les lire directement sur la sortie de
<code>stat</code> correspondant à l'inode. De surcroît,
<code>debugfs</code> a une commande qui automatise cette tâche.
Pour reprendre l'exemple précédent&nbsp;:</p>
<blockquote>
<pre><code>
debugfs:  stat &lt;148003&gt;
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
</code></pre></blockquote>
<p>Ce fichier a six blocs. Puisqu'il est en-dessous de la limite
des 12, nous demandons à <code>debugfs</code> d'écrire le fichier
dans un nouvel endroit, comme par exemple
<code>/mnt/recovered.000</code>&nbsp;:</p>
<blockquote>
<pre><code>
debugfs:  dump &lt;148003&gt; /mnt/recovered.000
</code></pre></blockquote>
<p>Bien sûr, on peut faire ça aussi avec <code>fsgrab</code>&nbsp;;
je le montre ici en guise d'exemple d'utilisation&nbsp;:</p>
<blockquote>
<pre><code>
# fsgrab -c 2 -s 594810 /dev/hda5 &gt; /mnt/recovered.000
# fsgrab -c 4 -s 594814 /dev/hda5 &gt;&gt; /mnt/recovered.000
</code></pre></blockquote>
<p>Que ce soit avec <code>debugfs</code> ou avec
<code>fsgrab</code>, il y aura un peu de déchet à la fin de
<code>/mnt/recovered.000</code>, mais ce n'est pas très important.
Si vous voulez vous en débarrasser, la méthode la plus simple est
de prendre le champ <code>Size</code> de l'inode, et le brancher
sur l'option <code>bs</code> d'une ligne de commande
<code>dd</code>.</p>
<blockquote>
<pre><code>
# dd count=1 if=/mnt/recovered.000 of=/mnt/resized.000 bs=6065
</code></pre></blockquote>
<p>Bien sûr, il est possible qu'un ou plusieurs blocs où était
écrit votre fichier aient été écrasés. Si c'est le cas, pas de
chance&nbsp;: le bloc est mort et enterré (rendez-vous compte, si
seulement vous aviez démonté plus tôt&nbsp;!).</p>
<h2><a name="ss10.2">10.2 Les fichiers plus longs</a></h2>
<p>Les problèmes apparaissent lorsque le fichier tient sur plus de
12 blocs de données. Ici, il vaut mieux en savoir un peu sur la
manière dont sont structurés les systèmes de fichiers Unix. Les
données du fichier sont stockées dans des unités appelées � blocs
�. Ces blocs peuvent être numérotés séquentiellement. Un fichier a
également un � inode �, où sont placées des informations telles que
propriétaire, permissions ou type. Comme les blocs, les inodes sont
numérotés séquentiellement, bien que la séquence soit différente.
Une entrée de répertoire consiste en un nom de fichier associé à un
numéro d'inode.</p>
<p>Mais, si on en restait là, le noyau ne saurait toujours pas
trouver les données correspondant à une entrée de répertoire. Ainsi
l'inode indique également l'endroit où se trouvent les blocs de
données du fichier, comme suit&nbsp;:</p>
<ul>
<li>Les numéros de blocs des 12 premiers blocs sont indiqués
directement dans l'inode (on les appelle parfois <em>blocs
directs</em>)&nbsp;;</li>
<li>L'inode contient le numéro de bloc d'un <em>bloc indirect</em>.
Un bloc indirect contient les numéros de bloc de 256 blocs de
données additionnels&nbsp;;</li>
<li>L'inode contient le numéro de bloc d'un <em>bloc doublement
indirect</em>. Un bloc doublement indirect contient les numéros de
bloc de blocs indirects supplémentaires&nbsp;;</li>
<li>L'inode contient le numéro de bloc d'un bloc <em>triplement
indirect</em>. Un bloc triplement indirect contient les numéros de
bloc de 256 blocs doublement indirects supplémentaires.</li>
</ul>
<p>Relisez bien tout ça&nbsp;: je sais que c'est compliqué, mais
c'est important, aussi.</p>
<p>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 numéros de tous
les blocs dont vous avez besoin (sans parler de leur contenu).</p>
<p>La seule méthode que j'aie pu trouver jusqu'ici consiste à
supposer que le fichier n'est pas fragmenté&nbsp;: 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 données, selon le nombre
de blocs de données utilisés par le fichier&nbsp;:</p>
<dl>
<dt><b>0 à 12</b></dt>
<dd>
<p>les numéros de bloc sont indiqués dans l'inode, comme décrit
précédemment&nbsp;;</p>
</dd>
<dt><b>13 à 268</b></dt>
<dd>
<p>après les blocs directs, comptez un pour le bloc indirect, puis
vous avez 256 blocs de données&nbsp;;</p>
</dd>
<dt><b>269 à 65804</b></dt>
<dd>
<p>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 répétitions de&nbsp;: un bloc indirect
(inutile) et 256 blocs de données&nbsp;;</p>
</dd>
<dt><b>65805 ou plus</b></dt>
<dd>
<p>la disposition des 65804 premiers blocs est identique à ce qui
est décrit di-dessus. Suivent un bloc triplement indirect (inutile)
et 256 répétitions d'une séquence � doublement indirect �. Chaque
séquence doublement indirecte consiste en un bloc doublement
indirect (inutile), suivi de 256 répétitions de&nbsp;: un bloc
indirect (inutile) et 256 blocs de données.</p>
</dd>
</dl>
<p>Bien entendu, même si ces blocs sont supposés corrects, rien ne
garantit que les données 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 système de fichiers sans fragmentation
raisonnable (sauf dans certaines circonstances particulières).</p>
<p>Notez que j'ai supposé depuis le début 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 changés. Typiquement, puisque chaque numéro de bloc
occupe 4 octets, le nombre de numéros de bloc pouvant être placés
dans chaque bloc indirect est taille_du_bloc/4. Donc, chaque fois
que le nombre 256 apparaît dans la dicussion qui précède,
remplacez-le par taille_du_bloc/4. Les limitations � nombre de
blocs requis � devront également être modifiées.</p>
<p>Examinons un exemple de récupération de fichier plus long.</p>
<blockquote>
<pre><code>
debugfs:  stat &lt;1387&gt;
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
</code></pre></blockquote>
<p>Il semble y avoir de bonnes chances pour que ce fichier ne soit
pas fragmenté&nbsp;: de façon évidente, les 12 premiers blocs
listés dans l'inode (qui sont tous des blocs de données) sont
contigus. Nous pouvons donc commencer par récupérer ces
blocs&nbsp;:</p>
<blockquote>
<pre><code>
# fsgrab -c 12 -s 8314 /dev/hda5 &gt; /mnt/recovered.001
</code></pre></blockquote>
<p>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 données (du numéro
8327 au numéro 8582).</p>
<blockquote>
<pre><code>
# fsgrab -c 256 -s 8327 /dev/hda5 &gt;&gt; /mnt/recovered.001
</code></pre></blockquote>
<p>Le dernier bloc listé dans l'inode est le 8583. Notez que ça
ressemble toujours bien à un fichier contigu&nbsp;: le numéro 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 répétitions d'un bloc
indirect (ignoré) suivi de 256 blocs de données. Après un petit
calcul mental, on en déduit les commandes suivantes. Remarquez
qu'on saute le bloc doublement indirect 8583 et le bloc indirect
8584, qui suivent immédiatement (espérons-le) et qu'on commence
directement à lire les données depuis le bloc 8585.</p>
<blockquote>
<pre><code>
# fsgrab -c 256 -s 8585 /dev/hda5 &gt;&gt; /mnt/recovered.001
# fsgrab -c 256 -s 8842 /dev/hda5 &gt;&gt; /mnt/recovered.001
# fsgrab -c 256 -s 9099 /dev/hda5 &gt;&gt; /mnt/recovered.001
# fsgrab -c 256 -s 9356 /dev/hda5 &gt;&gt; /mnt/recovered.001
# fsgrab -c 256 -s 9613 /dev/hda5 &gt;&gt; /mnt/recovered.001
# fsgrab -c 256 -s 9870 /dev/hda5 &gt;&gt; /mnt/recovered.001
</code></pre></blockquote>
<p>En rassemblant tout, on voit qu'on a écrit depuis le début 12 +
(7 * 256) blocs, c'est-à-dire 1804. La commande � stat � nous a
indiqué pour l'inode un � <em>blockcount</em> � de 3616&nbsp;; mais
ces blocs occupaient malheureusement 512 octets (un reliquat
d'Unix), ce que nous voulons réellement 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 données écrit portait
le numéro 10125. De la même façon que depuis le début, on saute un
bloc indirect (numéro 10126)&nbsp;; on peut alors écrire ces quatre
derniers blocs.</p>
<blockquote>
<pre><code>
# fsgrab -c 4 -s 10127 /dev/hda5 &gt;&gt; /mnt/recovered.001
</code></pre></blockquote>
<p>Et maintenant, avec un peu de chance, le fichier complet a été
récupéré avec succès.</p>
<h2><a name="sec-modify"></a> <a name="s11">11. Modifier les inodes
directement</a></h2>
<p>Cette méthode est apparemment beaucoup plus facile. Cependant,
comme souligné plus haut, elle ne peut pas venir à bout de fichiers
occupant plus de 12 blocs.</p>
<p>Pour chaque inode que vous voulez récupérer, vous devez mettre à
1 le nombre de liens, et à 0 la date de suppression. Cela peut être
fait grâce à la commande <code>mi</code> (modifier inode) de
<code>debugfs</code>. Voici un exemple de sortie concernant la
modification de l'inode 148003&nbsp;:</p>
<blockquote>
<pre><code>
debugfs:  mi &lt;148003&gt;
                        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]
</code></pre></blockquote>
<p>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 très souple si vous avez
beaucoup de fichiers à récupérer, mais je pense que vous pourrez
faire face. Si vous vouliez du velours, il fallait utiliser un �
système d'exploitation � graphique avec une jolie � corbeille
�.</p>
<p>À propos, le texte de sortie de <code>mi</code> indique un champ
� création � (<em>creation time</em>). Il est totalement mensonger
(ou en tout cas trompeur)&nbsp;! En fait, sur un système de
fichiers Unix, vous ne pouvez pas déterminer quand un fichier a été
créé. Le champ <code>st_ctime</code> d'une <code>struct stat</code>
fait référence à la date de modification de l'inode (<em>inode
change time</em>), c'est-à-dire la dernière fois qu'un quelconque
des détails de l'inode a été changé. Si finit la lessons d'huy.</p>
<p>Notez que les versions plus récentes de <code>debugfs</code> que
celle que j'utilise n'incluent probablement pas certains des champs
de la liste donnée plus haut (typiquement <code>Reserved1</code> et
des champs sur les fragments).</p>
<p>Une fois que vous aurez modifié les inodes, vous pourrez quitter
<code>debugfs</code> et taper&nbsp;:</p>
<blockquote>
<pre><code>
# e2fsck -f /dev/hda5
</code></pre></blockquote>
<p>L'idée est que chacun des fichiers supprimés a été littéralement
� dé-supprimé �, mais qu'aucun d'entre eux n'apparaît en entrée de
répertoire. Le programme <code>e2fsck</code> peut le détecter, et
ajoutera une entrée dans le répertoire <code>/lost+found</code> du
système de fichiers (Donc, si la partition est normalement montée
dans <code>/usr</code>, les fichiers vont apparaître dans
<code>/usr/lost+found</code>). Tout ce qui reste à faire est de
redonner son nom à chaque fichier d'après son contenu, et le
remettre à sa place dans l'arborescence du système de fichiers.</p>
<p>Quand vous lancerez <code>e2fsck</code>, vous obtiendrez des
messages d'information, ainsi que des questions à propos des
problèmes à réparer. Répondez oui (<em>yes</em>) partout où vous
voyez <em>`summary information'</em> ou à chaque référence aux
inodes que vous avez modifiés. Tout le reste vous regarde, bien
qu'il soit en général une bonne idée de répondre oui à toutes les
questions. Lorsque <code>e2fsck</code> a terminé, vous pouvez
remonter le système de fichiers.</p>
<p>En fait, il y a un autre moyen que de demander à
<code>e2fsck</code> de laisser les fichiers dans
<code>/lost+found</code>&nbsp;: vous pouvez utiliser
<code>debugfs</code> pour créer un lien vers l'inode dans le
système de fichiers. Utilisez la commande <code>link</code> de
<code>debugfs</code> quand vous avez fini de modifier l'inode.</p>
<blockquote>
<pre><code>
debugfs:  link &lt;148003&gt; toto.txt
</code></pre></blockquote>
<p>Ceci crée un fichier appelé <code>toto.txt</code> dans ce que
<code>debugfs</code> suppose être le répertoire courant&nbsp;;
<code>toto.txt</code> sera votre fichier. Vous aurez quand même
besoin de lancer <code>e2fsck</code> pour corriger le <em>`summary
information'</em>, le nombre de blocs, etc.</p>
<h2><a name="sec-easier"></a> <a name="s12">12. Cela va-t-il se
simplifier dans l'avenir&nbsp;?</a></h2>
<p>Oui. En fait, je pense que c'est déjà le cas. Bien qu'au moment
où ces lignes sont écrites (2 février 1999), les noyaux stables
actuels (la série 2.0.x) effacent les blocs indirects, ce n'est
plus le cas des noyaux de développement 2.1.x, ni des noyaux
stables 2.2.x, dont le 2.2.1 qui vient d'être diffusé&nbsp;; nous
allons voir apparaître des distributions à base de noyaux 2.2.x
d'ici un ou deux mois.</p>
<p>Une fois cette limitation retirée des noyaux stables, bon nombre
de mes objections au fait de modifier les inodes à la main
disparaîtront. Il sera également possible d'utiliser la commande
<code>dump</code> de <code>debugfs</code> sur des fichiers longs,
et d'utiliser d'autres outils de récupération.</p>
<h2><a name="s13">13. Existe-t-il des outils qui automatisent le
processus&nbsp;?</a></h2>
<p>En fait, il y en a. Hélas, je crains qu'ils souffrent du même
problème que la technique de modification manuelle des
inodes&nbsp;: les blocs indirects sont irrécupérables. Cependant,
selon la probabilité que cela ne soit plus un problème d'ici peu,
ça vaut sûrement le coup de chercher ces programmes maintenant.</p>
<p>J'ai écrit un utilitaire nommé <code>e2recover</code>, qui est
essentiellement un enrobage Perl à <code>fsgrab</code>. Il fait un
effort raisonnable pour gérer les blocs indirects effacés, et
semble très bien fonctionner en l'absence de fragmentation. Il en
profite pour remettre les permissions (et, quand c'est possible, le
propriétaire) des fichiers récupérés, et s'assure même que les
fichiers récupérés soient à la bonne taille.</p>
<p>J'ai initialement écrit <code>e2recover</code> pour la toute
proche mise à jour de ce Howto&nbsp;; malheureusement cela signifie
que tous les renseignements utiles sur <code>e2recover</code> sont
aussi prévus pour cette mise à jour. En attendant, il devrait
s'avérer quand même utile dès maintenant&nbsp;; vous pouvez le
télécharger depuis <a href=
"http://pobox.com/~aaronc/tech/e2-undel/">ma page</a>, et
prochainement sur Metalab.</p>
<p>Scott D. Heavner est l'auteur de <code>lde</code>, (`Linux Disk
Editor'). <code>lde</code> peut servir aussi bien d'éditeur binaire
de disque, que d'un équivalent de <code>debugfs</code> pour les
systèmes ext2 et minix, et même pour les systèmes xia (bien que le
support xia ne soit plus disponible dans les noyaux 2.1.x et
2.2.x). Il dispose de fonctionnalités pour faciliter la
récupération, comme le parcours de la liste des blocs, et la
recherche dans le contenu du disque. Il possède également une
documentation sur les concepts de base des systèmes de fichiers
particulièrement utile, ainsi qu'un document expliquant comment
l'utiliser afin de récupérer des fichiers supprimés. La version 2.4
de <code>lde</code> est disponible sur <a href=
"http://metalab.unc.edu/pub/Linux/system/filesystems/lde-2.4.tar.gz">
Metalab</a> et ses mirroirs, et sur <a href=
"http://www.geocities.com/CapeCanaveral/Lab/7731/lde.html">la page
de son auteur</a>.</p>
<p>Une autre possibilité est fournie par le GNU Midnight Commander,
<code>mc</code>. C'est un gestionnaire de fichiers en plein écran,
inspiré autant que je le sache d'un certain programme MS-DOS
couramment désigné sous le nom de � nc �. <code>mc</code> supporte
la souris dans la console Linux et dans un xterm, et fournit des
systèmes de fichiers virtuels qui permettent des trucs du genre de
se déplacer dans une archive Tar. Parmi ses systèmes de fichiers
virtuels, il en est un concernant la récupération sous Ext2. Tout
ça semble très commode à manipuler, mais je dois avouer que que je
ne l'ai jamais utilisé moi-même -- je préfère les bonnes vieilles
commandes <em>shell</em>. Apparemment il faut configurer le
programme avec l'option <code>--with-ext2undel</code>&nbsp;; vous
aurez également besoin des bibliothèques de développement et des
fichiers d'en-tête (<em>include</em>) qui viennent avec le
paquetage <code>e2fsprogs</code>. La version fournie par <a href=
"http://www.debian.org/">Debian GNU/Linux</a> est ainsi
compilé&nbsp;; c'est peut-être le cas pour d'autres distributions.
Une fois que le programme est compilé, vous pouvez y taper <code>cd
undel:/dev/hda5/</code>, et obtenir, sous forme de contenu de
répertoire, le catalogue des fichiers supprimés. Comme la plupart
des outils actuels de récupération, il gère très mal les blocs
indirects effacés -- la plupart du temps il ne récupère que les 12
premiers Ko des gros fichiers.</p>
<p>La dernière version peut être récupérée depuis <a href=
"ftp://ftp.nuclecu.unam.mx/Midnight/devel">le site ftp
officiel</a>.</p>
<h2><a name="s14">14. Achevé d'imprimer...</a></h2>
<p>J'ai l'intention de produire des mises à jour régulières de ce
document, tant que j'aurai à la fois suffisamment de temps pour le
faire et quelque chose d'intéressant à dire. Ceci signifie que je
suis avide de commentaires de la part de mes lecteurs. Ma rédaction
peut-elle être plus claire&nbsp;? Pouvez-vous penser à quelque
chose qui pourrait rendre l'affaire plus simple&nbsp;? Existe-t-il
un nouvel outil qui puisse faire tout cela
automatiquement&nbsp;?</p>
<p>Quoi qu'il en soit&nbsp;: si vous avez quoi que ce soit à dire,
à propos de ce document ou des outils <code>fsgrab</code> et
<code>e2recover</code>, envoyez-moi un mot à&nbsp;:</p>
<p><code><a href=
"mailto:aaronc@pobox.com">aaronc@pobox.com</a></code>.</p>
<h2><a name="sec-credits"></a> <a name="s15">15. Remerciements et
bibliographie</a></h2>
<blockquote><em>Si j'ai vu plus loin que d'autres, c'est parce que
j'étais hissé sur des épaules de géants</em> (Isaac
Newton)</blockquote>
<p>Une grande partie de ce mini-Howto est dérivée d'un article
posté sur le groupe de <em>news</em> <code><a href=
"news:comp.os.linux.misc">comp.os.linux.misc</a></code> par Robin
Glover <code><a href=
"mailto:swrglovr@met.rdg.ac.uk">swrglovr@met.rdg.ac.uk</a></code>.</p>
<p>Je voudrais remercier Robin de m'avoir gracieusement autorisé à
reprendre ses idées dans ce mini-Howto.</p>
<p>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 reçoit qui
justifient la peine que l'on se donne.</p>
<p>Quelques références bibliographiques&nbsp;:</p>
<ul>
<li><b>Frisch</b>, Æleen (1995), <em>Essential System
Administration</em>, second edition, O'Reilly and Associates, Inc.,
ISBN&nbsp;: 1-56592-127-5.</li>
<li><b>Garfinkel</b>, Simson, Daniel <b>Weise</b> et Steven
<b>Strassmann</b> (1994), <em>The Unix-Haters Handbook</em>, IDG
Books, ISBN&nbsp;: 1-56884-203-1. Ce livre est composé pour la plus
grande partie de pleurs d'adolescents qui pensent que <em>leur</em>
système 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&nbsp;; par exemple, la discussion autour de la
facilité d'effacement de fichier sous Unix mérite qu'on s'y
arrête.</li>
<li><b>Glover</b>, Robin (31 Jan 1996), <em>HOW-TO&nbsp;: undelete
linux files (ext2fs/debugfs)</em>, comp.os.linux.misc Usenet
posting.</li>
<li><b>Peek</b>, Jerry, Tim <b>O'Reilly</b>, Mike <b>Loukides</b>
<em>et al</em> (1993), <em>UNIX Power Tools</em>, O'Reilly and
Associates, Inc./Random House, Inc., ISBN&nbsp;:
0-679-79073-X.</li>
</ul>
<h2><a name="s16">16. Bla-bla juridique</a></h2>
<p>Toutes les marques déposées sont la propriété de leurs auteurs
respectifs. Spécifiquement&nbsp;:</p>
<ul>
<li><em>MS-DOS</em> et <em>Windows</em> sont des marques déposées
de <a href="http://www.microsoft.com/">Microsoft</a>&nbsp;;</li>
<li><em>UNIX</em> est une marque déposée de <em><a href=
"http://www.open.org/">the Open Group</a></em>&nbsp;;</li>
<li><em>Linux</em> est une marque déposée de Linus Torvalds aux USA
et dans quelques autres pays.</li>
</ul>
<p>Ce document est Copyright � 1997, 1999 Aaron Crane
<code><a href="mailto:aaronc@pobox.com">aaronc@pobox.com</a></code>.
Il peut être librement et entièrement 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 dérogation est
cependant accordée dans le cas de la copie de courts extraits sans
modification pour des revues ou une citation&nbsp;; dans ces
circonstances, les sections peuvent être reproduites accompagnées
d'une citation appropriée mais sans cette note de copyright.</p>
<p>L'auteur demande, mais n'exige pas, que des parties souhaitant
vendre des copies de ce document, sur un <em>medium</em> lisible
par un ordinateur ou par un humain, informent de leurs intentions,
soit l'auteur, soit le coordinateur des HOWTO Linux.</p>
<p>Le coordinateur des HOWTO Linux est actuellement Tim Bynum
<code><a href=
"mailto:linux-howto@metalab.unc.edu">linux-howto@metalab.unc.edu</a></code>.</p>
</body>
</html>
doc-linux-fr-html 2013.01-3ubuntu1 / usr / share / doc / HOWTO / fr-html / Ext2fs-Undeletion.html
