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.