Page suivantePage précédenteTable des matières

11. Modifier les inodes directement

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.


Page suivantePage précédenteTable des matières