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.
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 !).
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 :
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 :
les num�ros de bloc sont indiqu�s dans l'inode, comme d�crit pr�c�demment ;
apr�s les blocs directs, comptez un pour le bloc indirect, puis vous avez 256 blocs de donn�es ;
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 ;
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 � blockcount � 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.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:26