Linux Ext2fs Undeletion mini-HOWTO
Aaron Crane,
[email protected]
v1.3, 2 F�vrier 1999
(Adaptation fran�aise par Miodrag Vallat <mailto:miodrag@multima�
nia.com>, anciennement par G�raud Canet <mailto:
[email protected]�
deaux.fr> et Sylviane Regnault <mailto:
[email protected]�
deaux.fr>). 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 : vous avez achev�
ce programme qui vous apportera gloire et admiration du monde entier.
Allez, plus qu'� archiver tout �a et l'envoyer � Metalab. Ah, et puis
virer toutes ces sauvegardes automatiques d'Emacs. Alors vous tapez
rm * ~. Et, trop tard, vous remarquez l'espace en trop. Vous avez
d�truit votre _o_e_u_v_r_e _m_a_�_t_r_e_s_s_e ! 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...
______________________________________________________________________
Table des mati�res
1. Introduction
1.1 Historique des r�visions
1.1.1 Nouveaut�s de la version 1.1
1.1.2 Nouveaut�s de la version 1.2
1.1.3 Nouveaut�s de la version 1.3
1.2 O� trouver ce document
2. Comment ne pas supprimer de fichiers
3. � quel taux de r�cup�ration puis-je m'attendre ?
4. Bon, alors comment je r�cup�re un fichier ?
5. D�monter le syst�me de fichiers
6. Pr�parer la modification directe des inodes
7. Pr�parer l'�criture � un autre endroit
8. Trouver les inodes supprim�s
9. Obtenir des d�tails sur les inodes
10. R�cup�rer les blocs de donn�es
10.1 Les fichiers courts
10.2 Les fichiers plus longs
11. Modifier les inodes directement
12. Cela va-t-il se simplifier dans l'avenir ?
13. Existe-t-il des outils qui automatisent le processus ?
14. Achev� d'imprimer...
15. Remerciements et bibliographie
16. Bla-bla juridique
______________________________________________________________________
11.. IInnttrroodduuccttiioonn
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.
Mon but est naturellement d'en faire une r�f�rence utile � tous ceux
qui ont eu un, disons... accident avec rm ; mais cependant je souhaite
que les gens le lisent de toute fa�on. On ne sait jamais : un jour,
les renseignements donn�s ici pourraient vous sauver la couenne.
La lecture de ce texte suppose un minimum de connaissances sur les
syst�mes de fichiers Unix ; 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
_e_x_i_g_e certaines connaissances techniques, ainsi que de la
pers�v�rance, au moins dans l'�tat actuel des choses.
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 _r_o_o_t, mais plusieurs
distributions (comme Debian GNU/Linux) disposent d'un groupe disk dont
les membres ont ces acc�s. Vous aurez �galement besoin de la commande
debugfs, du paquetage e2fsprogs, qui devrait avoir �t� install� par
votre distribution.
Pourquoi ai-je �crit ceci ? Principalement par exp�rience personnelle,
souvenir du d�sastre d'un rm -r particuli�rement insens� en tant que
_r_o_o_t. J'ai supprim� 97 fichiers JPEG dont j'avais besoin et que je ne
pouvais certainement pas r�cup�rer par ailleurs. Suivant quelques
conseils (voir la section ``Remerciements et bibliographie'') 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 ; 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 r�cup�ration que vous pouvez esp�rer
pour les fichiers supprim�s.
11..11.. HHiissttoorriiqquuee ddeess rr��vviissiioonnss
Les r�visions de ce document (en version anglaise, NdT) d�livr�es au
public, ainsi que leurs dates de publication, sont les suivantes :
� v1.0, 18 janvier 1997 ;
� v1.1, 23 juillet 1997 (voir ``Nouveaut�s v1.1'') ;
� v1.2, 4 ao�t 1997 (voir ``Nouveaut�s v1.2'') ;
� v1.3, 2 f�vrier 1999 (voir ``Nouveaut�s v1.3'').
11..11..11.. NNoouuvveeaauutt��ss ddee llaa vveerrssiioonn 11..11
Quels sont les nouveaut�s de cette version ? 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 ; cela m'apprendra,
je l'esp�re, � faire plus attention en inventant des s�quences
interactives.
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�.
Tertio, le gros-tas-de-tar-gzip-uu-encod� de fsgrab au milieu du
fichier a �t� retir�. Le programme est d�sormais disponible sur ma
page <
http://pobox.com/~aaronc/tech/fsgrab-1.2.tar.gz> et sur Metalab
<
http://metalab.unc.edu/pub/Linux/utils/file/> (et ses miroirs).
Quarto, le document a �t� traduit en langage sgml, utilis� par le
Linux Documentation Project. Ce langage peut �tre facilement converti
en un grand nombre d'autres langages (y compris HTML et LaTeX) pour un
affichage et une impression simples et pratiques. Cela a pour
avantage une belle typographie, dans le cas d'une �dition papier ; de
plus, le document contient des r�f�rences et des liens bien commodes
si vous le consultez sur le Web.
11..11..22.. NNoouuvveeaauutt��ss ddee llaa vveerrssiioonn 11..22
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.
Le premier changement a �t� sugg�r� par Egil Kvaleberg
[email protected], qui a signal� la commande dump dans debugfs. Merci
encore, Egil.
Le second changement a �t� de signaler l'utilisation de chattr pour
�viter de supprimer des fichiers importants. Merci � Herman Suijs
[email protected] de l'avoir signal�.
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.).
11..11..33.. NNoouuvveeaauutt��ss ddee llaa vveerrssiioonn 11..33
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 lde, ont
�t� revus. Oh, et j'ai remplac� `Sunsite' par `Metalab' partout.
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.
11..22.. OO�� ttrroouuvveerr ccee ddooccuummeenntt
La version officielle la plus r�cente de ce document devrait �tre
disponible au format texte aupr�s du site du Linux Documentation
Project <
http://metalab.unc.edu/LDP/> (et ses miroirs). La derni�re
version est �galement disponible sur ma page
<
http://pobox.com/~aaronc/> sous divers formats :
� source SGML <
http://pobox.com/~aaronc/tech/e2-undel/howto.sgml>,
tel que je l'ai �crit ;
� HTML <
http://pobox.com/~aaronc/tech/e2-undel/html/>, g�n�r�
automatiquement depuis le source SGML ;
� format texte <
http://pobox.com/~aaronc/tech/e2-undel/howto.txt>,
�galement g�n�r� automatiquement depuis le source SGML.
22.. CCoommmmeenntt nnee ppaass ssuupppprriimmeerr ddee ffiicchhiieerrss
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� : 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.
Donc... r�gle num�ro un (ou premi�re directive, si vous pr�f�rez) :
FFAAIITTEESS DDEESS SSAAUUVVEEGGAARRDDEESS
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 ! -- si un cracker nettoyait votre disque sans vergogne. Ce
n'est pas si improbable ; 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 _s_'_y
_c_o_n_f_o_r_m_e_r. 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
``Bibliographie et remerciements'').
En l'absence de sauvegardes, que faire (en fait, m�me en pr�sence de
sauvegardes : dans le cas de donn�es importantes, la ceinture et les
bretelles, ce n'est pas du luxe) ?
Essayez de donner aux fichiers importants les droits 440 (ou moins) :
ne pas vous laisser les droits en �criture provoque une demande de
confirmation explicite de rm avant la destruction (mais si je veux
supprimer r�cursivement un r�pertoire avec rm -r, j'interromprai le
programme d�s la premi�re ou deuxi�me demande de confirmation pour
relancer la commande avec rm -rf).
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 /etc/passwd (et par l�-m�me d�truisait � moiti� le
syst�me). Un des rem�des 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 compl�tement le contenu du
fichier : si vous dites
# rm /etc/passwd
alors
# ln /.backup/passwd /etc
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.
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 chattr. Il y a un attribut �
ajout seulement � (_a_p_p_e_n_d_-_o_n_l_y) : 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
$ chattr +a FICHIER...
Il existe aussi un attribut � immuable � (_i_m_m_u_t_a_b_l_e), qui ne peut �tre
plac� ou retir� qu'en tant que _r_o_o_t. Un fichier ou 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 :
# chattr +i FICHIER...
Ext2fs fournit �galement l'attribut � r�cup�rable � (_u_n_d_e_l_e_t_a_b_l_e,
option +u de chattr). Si un fichier ayant cet attribut est supprim�,
mais pas 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 ; 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.
Certains d�fendent l'id�e de faire de rm un alias ou une fonction du
gestionnaire de commandes qui ex�cute en fait rm -i (qui demande
confirmation pour _t_o_u_s les fichiers � supprimer). En effet, certaines
versions de la distribution Red Hat <
http://www.redhat.com/> le font
par d�faut 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 diff�rent, ou simplement une autre machine,
o� votre fonction rm n'existera pas. Si vous vous attendez � une
confirmation, il est assez facile d'oublier o� vous �tes et sp�cifier
un peu trop de fichiers � supprimer. De m�me, les divers scripts et
programmes servant � remplacer rm sont, � mon humble avis, tr�s
dangereux.
Une solution un peu meilleure serait de commencer � utiliser un
paquetage qui manipulerait une destruction � recyclable � en
fournissant une commande qui ne s'appellerait pas rm. Pour plus de
d�tails, voir Peek _e_t _a_l (1993) (voir la section ``Bibliographie et
remerciements''). 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.
33.. �� qquueell ttaauuxx ddee rr��ccuupp��rraattiioonn ppuuiiss--jjee mm''aatttteennddrree ??
�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 : 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.
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.
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.
44.. BBoonn,, aalloorrss ccoommmmeenntt jjee rr��ccuupp��rree uunn ffiicchhiieerr ??
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 : 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.
Vous devez suivre plusieurs �tapes avant de commencer votre tentative
de r�cup�ration ; voir les sections ``D�monter le syst�me de
fichiers'', ``Pr�parer la modification directe des inodes'' et
``Pr�parer l'�criture � un autre endroit'' pour plus de d�tails. Pour
d�couvrir comment r�cup�rer r�ellement vos fichiers, voir les sections
``Trouver les inodes supprim�s'', ``Obtenir des d�tails sur les
inodes'', ``R�cup�rer des blocs de donn�es'' et ``Modifier les inodes
directement''.
55.. DD��mmoonntteerr llee ssyysstt��mmee ddee ffiicchhiieerrss
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
_l_e _p_l_u_s _t_�_t _p_o_s_s_i_b_l_e, d�s que vous vous �tes rendu compte que les
fichiers sont supprim�s.
La m�thode la plus simple est la suivante : en supposant que les
fichiers supprim�s soient dans la partition /usr, tapez :
# umount /usr
Vous pouvez cependant avoir besoin de garder certaines donn�es
disponibles dans /usr. Dans ce cas, remontez-le en mode lecture
seule :
# mount -o ro,remount /usr
Si les fichiers supprim�s �taient dans la partition racine, vous
devrez ajouter une option -n, afin d'emp�cher que l'op�ration de
montage ne d�clenche une �criture dans /etc/mtab :
# mount -n -o ro,remount /
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 _r_e_s_o_u_r_c_e _b_u_s_y). Il y a un programme
qui peut envoyer un signal � tout processus utilisant un fichier ou
point de montage donn� : c'est fuser. Pour la partition /usr, essayez
ceci :
# fuser -v -m /usr
Cela aura pour effet d'afficher la liste des processus concern�s. En
admettant qu'aucun d'entre eux n'est vital, vous pouvez taper
# fuser -k -v -m /usr
afin d'envoyer � chaque processus un SIGKILL (qui le tuera
d'autorit�), ou, par exemple,
# fuser -k -TERM -v -m /usr
pour envoyer plut�t � chacun un SIGTERM (qui priera le processus de
terminer proprement).
66.. PPrr��ppaarreerr llaa mmooddiiffiiccaattiioonn ddiirreeccttee ddeess iinnooddeess
Mon conseil ? 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 ``Cela
va-t-il se simplifier dans l'avenir~?'' pour plus d'information).
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 (_l_o_o_p_b_a_c_k _d_e_v_i_c_e) :
# cp /dev/hda5 /root/working
# mount -t ext2 -o loop /root/working /mnt
(Notez que les anciennes versions de mount peuvent avoir des probl�mes
pour faire cela. Si votre mount 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�).
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.
77.. PPrr��ppaarreerr ll''��ccrriittuurree �� uunn aauuttrree eennddrrooiitt
Vous devez vous assurer d'avoir quelque part une partition de secours.
Esp�rons-le, votre syst�me a plusieurs partitions : peut-�tre une
racine, une /usr, et une /home. Avec tout ce choix, aucun probl�me :
cr�ez simplement un nouveau r�pertoire dans l'une d'entre elles.
Si vous n'avez qu'une partition racine dans laquelle vous fourrez
tout, �a risque d'�tre un poil plus d�licat. Peut-�tre avez-vous une
partition MS-DOS ou Windows que vous pourriez utiliser ? Ou vous avez
le gestionnaire _r_a_m_d_i_s_k dans votre noyau, peut-�tre en module ? Pour
utiliser le _r_a_m_d_i_s_k (en supposant que votre noyau soit plus r�cent que
1.3.48), tapez les commandes suivantes :
# dd if=/dev/zero of=/dev/ram0 bs=1k count=2048
# mke2fs -v -m 0 /dev/ram0 2048
# mount -t ext2 /dev/ram0 /mnt
Cela a pour effet de cr�er un volume _r_a_m_d_i_s_k de 2 Mo, et de le monter
en /mnt.
Un petit mot d'avertissement : si vous utilisez kerneld (ou son
rempla�ant kmod 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 _r_a_m_d_i_s_k tant que vous n'avez pas copi� tous les
fichiers qu'il contient sur un support non volatile. Une fois que
vous l'aurez d�mont�, kerneld 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.
Si vous avez un lecteur Zip, Jaz, ou LS-120, ou quelque chose
d'�quivalent, il s'agit probablement d'une bonne place pour une
partition de secours. Sinon, il faudra faire avec les disquettes.
Une autre chose dont vous devriez avoir besoin est un programme
capable de lire les donn�es n�cessaires en plein milieu du
p�riph�rique contenant la partition. � la rigueur, dd pourrait le
faire, mais pour lire � partir de, disons, 600 Mo dans une partition
de 800 Mo, dd tient � lire les 600 premiers 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 fsgrab ;
vous pouvez trouver le paquetage des sources sur ma page
<
http://pobox.com/~aaronc/tech/fsgrab-1.2.tar.gz>, ou sur Metalab
<
http://metalab.unc.edu/pub/Linux/utils/file/> (et ses miroirs). Si
vous souhaitez utiliser cette m�thode, la suite de ce mini-HOWTO
suppose que vous avez fsgrab.
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 fsgrab.
Si vous avez besoin de fsgrab mais n'en voulez pas, il est fort simple
de traduire une ligne de commande avec fsgrab en une avec dd. Si on a
fsgrab -c _c_o_u_n_t -s _s_k_i_p _d_e_v_i_c_e
alors la commande dd correpondante (et g�n�ralement beaucoup plus
lente) est
dd bs=1k if=_d_e_v_i_c_e count=_c_o_u_n_t skip=_s_k_i_p
Je dois vous avertir que, bien que fsgrab ait parfaitement fonctionn�
pour moi, je ne puis prendre aucune responsabilit� sur son
comportement. C'�tait vraiment une bidouille rapide et sale pour
arriver � mes fins. Pour plus de d�tails sur l'absence de garantie,
consultez la section _N_o _W_a_r_r_a_n_t_y dans le fichier COPYING inclus dans
la distribution (li s'agit de la GPL, la licence publique g�n�rale
GNU).
88.. TTrroouuvveerr lleess iinnooddeess ssuupppprriimm��ss
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 debugfs. Lancez debugfs avec le nom du p�riph�rique sur
lequel le syst�me de fichiers r�side :
# debugfs /dev/hda5
Si vous souhaitez modifier les inodes directement, ajoutez une option
-w de mani�re � activer l'�criture sur le syst�me de fichiers :
# debugfs -w /dev/hda5
La commande debugfs permettant de trouver les inodes d�truits est
lsdel. Donc, tapez la commande suivante � l'invite :
debugfs: lsdel
Apr�s moult grincements et g�missements du disque, une longue liste
est envoy�e par un _p_i_p_e � votre _p_a_g_e_r favori (la valeur de $PAGER).
Maintenant vous aurez envie d'en sauver une copie autre part. Si vous
avez less, vous pouvez taper -o suivi du nom du fichier qui devra
contenir le r�sultat. Sinon, vous devrez vous arranger pour envoyer la
sortie ailleurs. Essayez ceci :
debugfs: quit
# echo lsdel | debugfs /dev/hda5 > lsdel.out
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.
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.
99.. OObbtteenniirr ddeess dd��ttaaiillss ssuurr lleess iinnooddeess
debugfs a une commande stat, 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 :
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 � r�cup�rer, vous souhaiterez
automatiser tout cela. En suposant que votre liste (d'apr�s lsdel)
d'inodes � r�cup�rer est dans lsdel.out, essayez ceci :
# cut -c1-6 lsdel.out | grep "[0-9]" | tr -d " " > inodes
Ce nouveau fichier inodes 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 :
# sed 's/^.*$/stat <\0>/' inodes | debugfs /dev/hda5 > stats
et stats contient la sortie de toutes les commandes stat.
1100.. RR��ccuupp��rreerr lleess bbllooccss ddee ddoonnnn��eess
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.
1100..11.. LLeess ffiicchhiieerrss ccoouurrttss
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 :
vous pouvez les lire directement sur la sortie de stat correspondant �
l'inode. De surcro�t, debugfs a une commande qui automatise cette
t�che. Pour reprendre l'exemple pr�c�dent :
debugfs: stat <148003>
Inode: 148003 Type: regular Mode: 0644 Flags: 0x0 Version: 1
User: 503 Group: 100 Size: 6065
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 12
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x31a9a574 -- Mon May 27 13:52:04 1996
atime: 0x31a21dd1 -- Tue May 21 20:47:29 1996
mtime: 0x313bf4d7 -- Tue Mar 5 08:01:27 1996
dtime: 0x31a9a574 -- Mon May 27 13:52:04 1996
BLOCKS:
594810 594811 594814 594815 594816 594817
TOTAL: 6
Ce fichier a six blocs. Puisqu'il est en-dessous de la limite des 12,
nous demandons � debugfs d'�crire le fichier dans un nouvel endroit,
comme par exemple /mnt/recovered.000 :
debugfs: dump <148003> /mnt/recovered.000
Bien s�r, on peut faire �a aussi avec fsgrab ; je le montre ici en
guise d'exemple d'utilisation :
# fsgrab -c 2 -s 594810 /dev/hda5 > /mnt/recovered.000
# fsgrab -c 4 -s 594814 /dev/hda5 >> /mnt/recovered.000
Que ce soit avec debugfs ou avec fsgrab, il y aura un peu de d�chet �
la fin de /mnt/recovered.000, 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 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 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 : le
bloc est mort et enterr� (rendez-vous compte, si seulement vous aviez
d�mont� plus t�t !).
1100..22.. LLeess ffiicchhiieerrss pplluuss lloonnggss
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.
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 :
� Les num�ros de blocs des 12 premiers blocs sont indiqu�s
directement dans l'inode (on les appelle parfois _b_l_o_c_s _d_i_r_e_c_t_s) ;
� L'inode contient le num�ro de bloc d'un _b_l_o_c _i_n_d_i_r_e_c_t. Un bloc
indirect contient les num�ros de bloc de 256 blocs de donn�es
additionnels ;
� L'inode contient le num�ro 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 num�ros de bloc de blocs
indirects suppl�mentaires ;
� L'inode contient le num�ro 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 num�ros de bloc de 256
blocs doublement indirects suppl�mentaires.
Relisez bien tout �a : je sais que c'est compliqu�, mais c'est
important, aussi.
Maintenant, l'implantation du noyau pour toutes les versions actuelles
(2.0.36 inclue) efface malheureusement tous les blocs indirects (et
doublement indirects, etc.) lors de la suppression d'un fichier.
Alors, si votre fichier occupait plus de 12 blocs, vous n'�tes pas
garanti de pouvoir retrouver les num�ros de tous les blocs dont vous
avez besoin (sans parler de leur contenu).
La seule m�thode que j'aie pu trouver jusqu'ici consiste � supposer
que le fichier n'est pas fragment� : s'il l'est, vous aurez des
ennuis. En supposant que le fichier n'est pas fragment�, il y a
plusieurs dispositions de blocs de donn�es, selon le nombre de blocs
de donn�es utilis�s par le fichier :
00 �� 1122
les num�ros de bloc sont indiqu�s dans l'inode, comme d�crit
pr�c�demment ;
1133 �� 226688
apr�s les blocs directs, comptez un pour le bloc indirect, puis
vous avez 256 blocs de donn�es ;
226699 �� 6655880044
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 : un bloc indirect
(inutile) et 256 blocs de donn�es ;
6655880055 oouu pplluuss
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 : un bloc indirect (inutile) et 256 blocs de donn�es.
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).
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.
Examinons un exemple de r�cup�ration de fichier plus long.
debugfs: stat <1387>
Inode: 148004 Type: regular Mode: 0644 Flags: 0x0 Version: 1
User: 503 Group: 100 Size: 1851347
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 3616
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x31a9a574 -- Mon May 27 13:52:04 1996
atime: 0x31a21dd1 -- Tue May 21 20:47:29 1996
mtime: 0x313bf4d7 -- Tue Mar 5 08:01:27 1996
dtime: 0x31a9a574 -- Mon May 27 13:52:04 1996
BLOCKS:
8314 8315 8316 8317 8318 8319 8320 8321 8322 8323 8324 8325 8326 8583
TOTAL: 14
Il semble y avoir de bonnes chances pour que ce fichier ne soit pas
fragment� : de 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 :
# fsgrab -c 12 -s 8314 /dev/hda5 > /mnt/recovered.001
Maintenant, le bloc suivant list� dans l'inode, 8326, est un bloc
indirect, que nous pouvons ignorer. Mais nous nous fions � notre
intuition qu'il sera suivi de 256 blocs de donn�es (du num�ro 8327 au
num�ro 8582).
# fsgrab -c 256 -s 8327 /dev/hda5 >> /mnt/recovered.001
Le dernier bloc list� dans l'inode est le 8583. Notez que �a ressemble
toujours bien � un fichier contigu : le 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.
# fsgrab -c 256 -s 8585 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 8842 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 9099 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 9356 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 9613 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 9870 /dev/hda5 >> /mnt/recovered.001
En rassemblant tout, on voit qu'on a �crit depuis le d�but 12 + (7 *
256) blocs, c'est-�-dire 1804. La commande � stat � nous a indiqu�
pour l'inode un � _b_l_o_c_k_c_o_u_n_t � de 3616 ; mais ces blocs occupaient
malheureusement 512 octets (un reliquat d'Unix), ce que nous voulons
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) ; on peut
alors �crire ces quatre derniers blocs.
# fsgrab -c 4 -s 10127 /dev/hda5 >> /mnt/recovered.001
Et maintenant, avec un peu de chance, le fichier complet a �t�
r�cup�r� avec succ�s.
1111.. MMooddiiffiieerr lleess iinnooddeess ddiirreecctteemmeenntt
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.
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 mi (modifier inode) de debugfs. Voici un exemple
de sortie concernant la modification de l'inode 148003 :
debugfs: mi <148003>
Mode [0100644]
User ID [503]
Group ID [100]
Size [6065]
Creation time [833201524]
Modification time [832708049]
Access time [826012887]
Deletion time [833201524] 0
Link count [0] 1
Block count [12]
File flags [0x0]
Reserved1 [0]
File acl [0]
Directory acl [0]
Fragment address [0]
Fragment number [0]
Fragment size [0]
Direct Block #0 [594810]
Direct Block #1 [594811]
Direct Block #2 [594814]
Direct Block #3 [594815]
Direct Block #4 [594816]
Direct Block #5 [594817]
Direct Block #6 [0]
Direct Block #7 [0]
Direct Block #8 [0]
Direct Block #9 [0]
Direct Block #10 [0]
Direct Block #11 [0]
Indirect Block [0]
Double Indirect Block [0]
Triple Indirect Block [0]
C'est-�-dire que je mets � 0 la date de suppression et le nombre de
liens � 1, puis j'envoie juste un retour chariot pour chacun des
autres champs. D'accord, ce n'est pas 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 �.
� propos, le texte de sortie de mi indique un champ � cr�ation �
(_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 syst�me de fichiers Unix, vous ne pouvez
pas d�terminer quand un fichier a �t� cr��. Le champ st_ctime d'une
struct stat fait r�f�rence � la date de modification de l'inode (_i_n_o_d_e
_c_h_a_n_g_e _t_i_m_e), c'est-�-dire la derni�re fois qu'un quelconque des
d�tails de l'inode a �t� chang�. Si finit la lessons d'huy.
Notez que les versions plus r�centes de debugfs que celle que
j'utilise n'incluent probablement pas certains des champs de la liste
donn�e plus haut (typiquement Reserved1 et des champs sur les
fragments).
Une fois que vous aurez modifi� les inodes, vous pourrez quitter
debugfs et taper :
# e2fsck -f /dev/hda5
L'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 e2fsck peut le d�tecter, et ajoutera une
entr�e dans le r�pertoire /lost+found du syst�me de fichiers (Donc, si
la partition est normalement mont�e dans /usr, les fichiers vont
appara�tre dans /usr/lost+found). 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.
Quand vous lancerez e2fsck, vous obtiendrez des messages
d'information, ainsi que des questions � propos des probl�mes �
r�parer. R�pondez oui (_y_e_s) partout o� vous voyez _`_s_u_m_m_a_r_y
_i_n_f_o_r_m_a_t_i_o_n_' ou � chaque 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 e2fsck a termin�,
vous pouvez remonter le syst�me de fichiers.
En fait, il y a un autre moyen que de demander � e2fsck de laisser les
fichiers dans /lost+found : vous pouvez utiliser debugfs pour cr�er un
lien vers l'inode dans le syst�me de fichiers. Utilisez la commande
link de debugfs quand vous avez fini de modifier l'inode.
debugfs: link <148003> toto.txt
Ceci cr�e un fichier appel� toto.txt dans ce que debugfs suppose �tre
le r�pertoire courant ; toto.txt sera votre fichier. Vous aurez quand
m�me 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.
1122.. CCeellaa vvaa--tt--iill ssee ssiimmpplliiffiieerr ddaannss ll''aavveenniirr ??
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� ; nous allons voir appara�tre des
distributions � base de noyaux 2.2.x d'ici un ou deux mois.
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 dump de debugfs sur
des fichiers longs, et d'utiliser d'autres outils de r�cup�ration.
1133.. EExxiissttee--tt--iill ddeess oouuttiillss qquuii aauuttoommaattiisseenntt llee pprroocceessssuuss ??
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 : 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.
J'ai �crit un utilitaire nomm� e2recover, qui est essentiellement un
enrobage Perl � fsgrab. 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.
J'ai initialement �crit e2recover pour la toute proche mise � jour de
ce Howto ; malheureusement cela signifie que tous les renseignements
utiles sur e2recover sont aussi pr�vus pour cette mise � jour. En
attendant, il devrait s'av�rer quand m�me utile d�s maintenant ; vous
pouvez le t�l�charger depuis ma page
<
http://pobox.com/~aaronc/tech/e2-undel/>, et prochainement sur
Metalab.
Scott D. Heavner est l'auteur de lde, (`Linux Disk Editor'). lde peut
servir aussi bien d'�diteur binaire de disque, que d'un �quivalent de
debugfs pour les 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 lde est disponible sur
Metalab
<
http://metalab.unc.edu/pub/Linux/system/filesystems/lde-2.4.tar.gz>
et ses mirroirs, et sur la page de son auteur
<
http://www.geocities.com/CapeCanaveral/Lab/7731/lde.html>.
Une autre possibilit� est fournie par le GNU Midnight Commander, mc.
C'est un gestionnaire de fichiers en plein �cran, inspir� autant que
je le sache d'un certain programme MS-DOS couramment d�sign� sous le
nom de � nc �. mc 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 _s_h_e_l_l. Apparemment il faut configurer le programme
avec l'option --with-ext2undel ; vous aurez �galement besoin des
biblioth�ques de d�veloppement et des fichiers d'en-t�te (_i_n_c_l_u_d_e) qui
viennent avec le paquetage e2fsprogs. La version fournie par Debian
GNU/Linux <
http://www.debian.org/> est ainsi compil� ; c'est peut-�tre
le cas pour d'autres distributions. Une fois que le programme est
compil�, vous pouvez y taper cd undel:/dev/hda5/, et obtenir, sous
forme de contenu de 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.
La derni�re version peut �tre r�cup�r�e depuis le site ftp officiel
<
ftp://ftp.nuclecu.unam.mx/Midnight/devel>.
1144.. AAcchheevv�� dd''iimmpprriimmeerr......
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 ? Pouvez-vous penser � quelque chose qui
pourrait rendre l'affaire plus simple ? Existe-t-il un nouvel outil
qui puisse faire tout cela automatiquement ?
Quoi qu'il en soit : si vous avez quoi que ce soit � dire, � propos de
ce document ou des outils fsgrab et e2recover, envoyez-moi un mot � :
[email protected].
1155.. RReemmeerrcciieemmeennttss eett bbiibblliiooggrraapphhiiee
_S_i _j_'_a_i _v_u _p_l_u_s _l_o_i_n _q_u_e _d_'_a_u_t_r_e_s_, _c_'_e_s_t _p_a_r_c_e _q_u_e _j_'_�_t_a_i_s
_h_i_s_s_� _s_u_r _d_e_s _�_p_a_u_l_e_s _d_e _g_�_a_n_t_s (Isaac Newton)
Une grande partie de ce mini-Howto est d�riv�e d'un article post� sur
le groupe de _n_e_w_s comp.os.linux.misc par Robin Glover
[email protected].
Je voudrais remercier Robin de m'avoir gracieusement autoris� �
reprendre ses id�es dans ce mini-Howto.
Je voudrais �galement profiter de l'occasion pour remercier une fois
de plus toutes les personnes qui m'ont contact� � propos de ce Howto.
Ce sont les remerciements chaleureux que l'on re�oit qui justifient la
peine que l'on se donne.
Quelques r�f�rences bibliographiques :
� FFrriisscchh, �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.
� GGaarrffiinnkkeell, Simson, Daniel WWeeiissee et Steven SSttrraassssmmaannnn (1994), _T_h_e
_U_n_i_x_-_H_a_t_e_r_s _H_a_n_d_b_o_o_k, IDG Books, ISBN : 1-56884-203-1. Ce livre
est compos� pour la plus grande partie de pleurs d'adolescents qui
pensent que _l_e_u_r 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 ; par exemple, la discussion
autour de la facilit� d'effacement de fichier sous Unix m�rite
qu'on s'y arr�te.
� GGlloovveerr, 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.
� PPeeeekk, Jerry, Tim OO''RReeiillllyy, Mike LLoouukkiiddeess _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.
1166.. BBllaa--bbllaa jjuurriiddiiqquuee
Toutes les marques d�pos�es sont la propri�t� de leurs auteurs
respectifs. Sp�cifiquement :
� _M_S_-_D_O_S et _W_i_n_d_o_w_s sont des marques d�pos�es de Microsoft
<
http://www.microsoft.com/> ;
� _U_N_I_X est une marque d�pos�e de _t_h_e _O_p_e_n _G_r_o_u_p
_<
http://www.open.org/> ;
� _L_i_n_u_x est une marque d�pos�e de Linus Torvalds aux USA et dans
quelques autres pays.
Ce document est Copyright � 1997, 1999 Aaron Crane
[email protected].
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 ; dans ces circonstances,
les sections peuvent �tre reproduites accompagn�es d'une citation
appropri�e mais sans cette note de copyright.
L'auteur demande, mais n'exige pas, que des parties souhaitant vendre
des copies de ce document, sur un _m_e_d_i_u_m lisible par un ordinateur ou
par un humain, informent de leurs intentions, soit l'auteur, soit le
coordinateur des HOWTO Linux.
Le coordinateur des HOWTO Linux est actuellement Tim Bynum linux-
[email protected].
