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 � (creation time). 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 (inode change
time), 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 (yes) partout o� vous voyez
`summary information' 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 `summary information', le nombre de blocs, etc.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:26