This file is indexed.

/usr/share/doc/HOWTO/fr-html/Ext2fs-Undeletion.html is in doc-linux-fr-html 2013.01-3.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

   1
   2
   3
   4
   5
   6
   7
   8
   9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58
  59
  60
  61
  62
  63
  64
  65
  66
  67
  68
  69
  70
  71
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115
 116
 117
 118
 119
 120
 121
 122
 123
 124
 125
 126
 127
 128
 129
 130
 131
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170
 171
 172
 173
 174
 175
 176
 177
 178
 179
 180
 181
 182
 183
 184
 185
 186
 187
 188
 189
 190
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226
 227
 228
 229
 230
 231
 232
 233
 234
 235
 236
 237
 238
 239
 240
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282
 283
 284
 285
 286
 287
 288
 289
 290
 291
 292
 293
 294
 295
 296
 297
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394
 395
 396
 397
 398
 399
 400
 401
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450
 451
 452
 453
 454
 455
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506
 507
 508
 509
 510
 511
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562
 563
 564
 565
 566
 567
 568
 569
 570
 571
 572
 573
 574
 575
 576
 577
 578
 579
 580
 581
 582
 583
 584
 585
 586
 587
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618
 619
 620
 621
 622
 623
 624
 625
 626
 627
 628
 629
 630
 631
 632
 633
 634
 635
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674
 675
 676
 677
 678
 679
 680
 681
 682
 683
 684
 685
 686
 687
 688
 689
 690
 691
 692
 693
 694
 695
 696
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730
 731
 732
 733
 734
 735
 736
 737
 738
 739
 740
 741
 742
 743
 744
 745
 746
 747
 748
 749
 750
 751
 752
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786
 787
 788
 789
 790
 791
 792
 793
 794
 795
 796
 797
 798
 799
 800
 801
 802
 803
 804
 805
 806
 807
 808
 809
 810
 811
 812
 813
 814
 815
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842
 843
 844
 845
 846
 847
 848
 849
 850
 851
 852
 853
 854
 855
 856
 857
 858
 859
 860
 861
 862
 863
 864
 865
 866
 867
 868
 869
 870
 871
 872
 873
 874
 875
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898
 899
 900
 901
 902
 903
 904
 905
 906
 907
 908
 909
 910
 911
 912
 913
 914
 915
 916
 917
 918
 919
 920
 921
 922
 923
 924
 925
 926
 927
 928
 929
 930
 931
 932
 933
 934
 935
 936
 937
 938
 939
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954
 955
 956
 957
 958
 959
 960
 961
 962
 963
 964
 965
 966
 967
 968
 969
 970
 971
 972
 973
 974
 975
 976
 977
 978
 979
 980
 981
 982
 983
 984
 985
 986
 987
 988
 989
 990
 991
 992
 993
 994
 995
 996
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for Linux (vers 25 March 2009), see www.w3.org">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.71">
<title>Linux Ext2fs Undeletion mini-HOWTO</title>
</head>
<body>
<h1>Linux Ext2fs Undeletion mini-HOWTO</h1>
<h2>Aaron Crane, <code><a href=
"mailto:aaronc@pobox.com">aaronc@pobox.com</a></code></h2>
v1.3, 2 F&eacute;vrier 1999
<hr>
<em>(Adaptation fran&ccedil;aise par <a href=
"mailto:miodrag@multimania.com">Miodrag Vallat</a>, anciennement
par <a href="mailto:canet@labri.u-bordeaux.fr">G&eacute;raud
Canet</a> et <a href=
"mailto:regnault@axpcalc.crpp.u-bordeaux.fr">Sylviane
Regnault</a>). Imaginez un peu. Vous avez pass&eacute; les trois
derniers jours sans dormir, sans manger, sans m&ecirc;me prendre
une douche. Votre bidouillomanie compulsive a enfin port&eacute;
ses fruits&nbsp;: vous avez achev&eacute; ce programme qui vous
apportera gloire et admiration du monde entier. Allez, plus
qu'&agrave; archiver tout &ccedil;a et l'envoyer &agrave; Metalab.
Ah, et puis virer toutes ces sauvegardes automatiques d'Emacs.
Alors vous tapez <code>rm * ~</code>. Et, trop tard, vous remarquez
l'espace en trop. Vous avez d&eacute;truit votre <em>oeuvre
ma&icirc;tresse</em>&nbsp;! Mais, heureusement, vous avez de l'aide
&agrave; port&eacute;e de main. Ce document pr&eacute;sente une
discussion de la r&eacute;cup&eacute;ration de fichiers
supprim&eacute;s depuis le Second syst&egrave;me de fichiers
&eacute;tendu ext2fs. Esp&eacute;rez, peut-&ecirc;tre pourrez-vous
distribuer votre programme malgr&eacute; tout...</em>
<hr>
<h2><a name="s1">1. Introduction</a></h2>
<p>Ce mini-HOWTO tente de fournir un certain nombre de conseils
dans le but de r&eacute;cup&eacute;rer des fichiers
supprim&eacute;s depuis un syst&egrave;me de fichiers ext2fs. Il
contient &eacute;galement une petite discussion sur les
mani&egrave;res de commencer par &eacute;viter de supprimer des
fichiers.</p>
<p>Mon but est naturellement d'en faire une r&eacute;f&eacute;rence
utile &agrave; tous ceux qui ont eu un, disons... accident avec
<code>rm</code>&nbsp;; mais cependant je souhaite que les gens le
lisent de toute fa&ccedil;on. On ne sait jamais&nbsp;: un jour, les
renseignements donn&eacute;s ici pourraient vous sauver la
couenne.</p>
<p>La lecture de ce texte suppose un minimum de connaissances sur
les syst&egrave;mes de fichiers Unix&nbsp;; je me suis cependant
efforc&eacute; de le rendre accessible &agrave; la plupart des
utilisateurs de Linux. Si vous &ecirc;tes un grand d&eacute;butant,
je crains que la r&eacute;cup&eacute;ration de fichiers sous Linux
<em>exige</em> certaines connaissances techniques, ainsi que de la
pers&eacute;v&eacute;rance, au moins dans l'&eacute;tat actuel des
choses.</p>
<p>Il vous sera impossible de r&eacute;cup&eacute;rer des fichiers
supprim&eacute;s depuis un syst&egrave;me de fichiers ext2 sans au
moins un acc&egrave;s en lecture au p&eacute;riph&eacute;rique
(fichier sp&eacute;cial) sur lequel le fichier &eacute;tait
plac&eacute;. En g&eacute;n&eacute;ral, cela signifie que vous
devez &ecirc;tre <em>root</em>, mais plusieurs distributions (comme
<a href="http://www.debian.org/">Debian GNU/Linux</a>) disposent
d'un groupe <code>disk</code> dont les membres ont ces
acc&egrave;s. Vous aurez &eacute;galement besoin de la commande
<code>debugfs</code>, du paquetage <code>e2fsprogs</code>, qui
devrait avoir &eacute;t&eacute; install&eacute; par votre
distribution.</p>
<p>Pourquoi ai-je &eacute;crit ceci&nbsp;? Principalement par
exp&eacute;rience personnelle, souvenir du d&eacute;sastre d'un
<code>rm -r</code> particuli&egrave;rement insens&eacute; en tant
que <em>root</em>. J'ai supprim&eacute; 97 fichiers JPEG dont
j'avais besoin et que je ne pouvais certainement pas
r&eacute;cup&eacute;rer par ailleurs. Suivant quelques conseils
(voir la section <a href="#sec-credits">Remerciements et
bibliographie</a>) et en pers&eacute;v&eacute;rant beaucoup, j'ai
r&eacute;cup&eacute;r&eacute; 91 fichiers intacts. Je suis parvenu
&agrave; en retrouver, au moins en partie, cinq autres
(suffisamment pour voir quelle &eacute;tait l'image
repr&eacute;sent&eacute;e par chacun). Une seule n'&eacute;tait pas
affichable, et m&ecirc;me pour celle-l&agrave;, je suis certain de
n'avoir pas perdu plus de 1024 octets (mais h&eacute;las depuis le
d&eacute;but du fichier&nbsp;; sachant que je ne connais rien du
format de fichier JFIF j'ai vraiment fait ce que j'ai pu).</p>
<p>Je discuterai plus bas du taux de r&eacute;cup&eacute;ration que
vous pouvez esp&eacute;rer pour les fichiers supprim&eacute;s.</p>
<h2><a name="ss1.1">1.1 Historique des r&eacute;visions</a></h2>
<p>Les r&eacute;visions de ce document (en version anglaise, NdT)
d&eacute;livr&eacute;es au public, ainsi que leurs dates de
publication, sont les suivantes&nbsp;:</p>
<ul>
<li>v1.0, 18 janvier 1997&nbsp;;</li>
<li>v1.1, 23 juillet 1997 (voir <a href=
"#sec-v1.1">Nouveaut&eacute;s v1.1</a>)&nbsp;;</li>
<li>v1.2, 4 ao&ucirc;t 1997 (voir <a href=
"#sec-v1.2">Nouveaut&eacute;s v1.2</a>)&nbsp;;</li>
<li>v1.3, 2 f&eacute;vrier 1999 (voir <a href=
"#sec-v1.3">Nouveaut&eacute;s v1.3</a>).</li>
</ul>
<h3><a name="sec-v1.1"></a> Nouveaut&eacute;s de la version
1.1</h3>
<p>Quels sont les nouveaut&eacute;s de cette version&nbsp;? Primo,
la r&eacute;flexion dans l'exemple de la r&eacute;cup&eacute;ration
de fichiers a &eacute;t&eacute; corrig&eacute;e. Merci &agrave;
tous ceux qui m'ont &eacute;crit pour me signaler mon erreur&nbsp;;
cela m'apprendra, je l'esp&egrave;re, &agrave; faire plus attention
en inventant des s&eacute;quences interactives.</p>
<p>Secundo, la discussion sur le mod&egrave;le de syst&egrave;me de
fichier Unix a &eacute;t&eacute; r&eacute;crite afin d'&ecirc;tre
(esp&eacute;rons-le) plus compr&eacute;hensible. Je n'en
&eacute;tais pas enti&egrave;rement satisfait de prime abord, et
d'aucuns se sont plaints de son manque de clart&eacute;.</p>
<p>Tertio, le gros-tas-de-tar-gzip-uu-encod&eacute; de
<code>fsgrab</code> au milieu du fichier a &eacute;t&eacute;
retir&eacute;. Le programme est d&eacute;sormais disponible sur
<a href="http://pobox.com/~aaronc/tech/fsgrab-1.2.tar.gz">ma
page</a> et sur <a href=
"http://metalab.unc.edu/pub/Linux/utils/file/">Metalab</a> (et ses
miroirs).</p>
<p>Quarto, le document a &eacute;t&eacute; traduit en langage sgml,
utilis&eacute; par le Linux Documentation Project. Ce langage peut
&ecirc;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 &eacute;dition papier&nbsp;; de plus, le document
contient des r&eacute;f&eacute;rences et des liens bien commodes si
vous le consultez sur le Web.</p>
<h3><a name="sec-v1.2"></a> Nouveaut&eacute;s de la version
1.2</h3>
<p>Cette r&eacute;vision est plut&ocirc;t une augmentation. Elle
inclut principalement des modifications propos&eacute;es par des
lecteurs, dont l'une est particuli&egrave;rement importante.</p>
<p>Le premier changement a &eacute;t&eacute; sugg&eacute;r&eacute;
par Egil Kvaleberg <code><a href=
"mailto:egil@kvaleberg.no">egil@kvaleberg.no</a></code>, qui a
signal&eacute; la commande <code>dump</code> dans
<code>debugfs</code>. Merci encore, Egil.</p>
<p>Le second changement a &eacute;t&eacute; de signaler
l'utilisation de <code>chattr</code> pour &eacute;viter de
supprimer des fichiers importants. Merci &agrave; Herman Suijs
<code><a href=
"mailto:H.P.M.Suijs@kub.nl">H.P.M.Suijs@kub.nl</a></code> de
l'avoir signal&eacute;.</p>
<p>Le r&eacute;sum&eacute; a &eacute;t&eacute; revu. Des URLs ont
&eacute;t&eacute; ajout&eacute;es, qui indiquent des organisations
ou des logiciels. Ajoutez &agrave; cela quelques modifications
mineures (dont des corrections de fautes de frappe, etc.).</p>
<h3><a name="sec-v1.3"></a> Nouveaut&eacute;s de la version
1.3</h3>
<p>Bien qu'il se soit &eacute;coul&eacute; 17 mois depuis la
derni&egrave;re version, bien peu de choses ont chang&eacute;.
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 &eacute;taient devenus
atrocement d&eacute;mod&eacute;s, comme ceux sur les versions de
noyau et <code>lde</code>, ont &eacute;t&eacute; revus. Oh, et j'ai
remplac&eacute; `Sunsite' par `Metalab' partout.</p>
<p>Cette version sera probablement la derni&egrave;re avant la
version 2.0, qui sera un vrai HOWTO, du moins je l'esp&egrave;re.
J'ai travaill&eacute; sur des changements d'importance qui
m&eacute;ritent l'incr&eacute;mentation du num&eacute;ro de version
majeure.</p>
<h2><a name="ss1.2">1.2 O&ugrave; trouver ce document</a></h2>
<p>La version officielle la plus r&eacute;cente de ce document
devrait &ecirc;tre disponible au format texte aupr&egrave;s du site
du <a href="http://metalab.unc.edu/LDP/">Linux Documentation
Project</a> (et ses miroirs). La derni&egrave;re version est
&eacute;galement disponible sur <a href=
"http://pobox.com/~aaronc/">ma page</a> sous divers
formats&nbsp;:</p>
<ul>
<li><a href=
"http://pobox.com/~aaronc/tech/e2-undel/howto.sgml">source
SGML</a>, tel que je l'ai &eacute;crit&nbsp;;</li>
<li><a href=
"http://pobox.com/~aaronc/tech/e2-undel/html/">HTML</a>,
g&eacute;n&eacute;r&eacute; automatiquement depuis le source
SGML&nbsp;;</li>
<li><a href=
"http://pobox.com/~aaronc/tech/e2-undel/howto.txt">format
texte</a>, &eacute;galement g&eacute;n&eacute;r&eacute;
automatiquement depuis le source SGML.</li>
</ul>
<h2><a name="s2">2. Comment ne pas supprimer de fichiers</a></h2>
<p>Il est vital de se rappeler que Linux n'est pas semblable
&agrave; MS-DOS en mati&egrave;re de r&eacute;cup&eacute;ration de
donn&eacute;es. Pour MS-DOS (et son b&acirc;tard Windows 95), il
est g&eacute;n&eacute;ralement tr&egrave;s simple de
r&eacute;cup&eacute;rer un fichier supprim&eacute;&nbsp;: le
&laquo; syst&egrave;me d'exploitation &raquo; (il faut le dire
vite) est m&ecirc;me accompagn&eacute; d'un utilitaire qui
automatise la proc&eacute;dure. Ce n'est pas le cas de Linux.</p>
<p>Donc... r&egrave;gle num&eacute;ro un (ou premi&egrave;re
directive, si vous pr&eacute;f&eacute;rez)&nbsp;:</p>
<blockquote><b>FAITES DES SAUVEGARDES</b></blockquote>
<p>peu importe comment. Pensez &agrave; toutes vos donn&eacute;es.
Peut-&ecirc;tre, comme moi, conservez-vous plusieurs ann&eacute;es
d'archives de messages, contacts, documents sur votre ordinateur.
Pensez au chamboulement dans votre vie si vous &eacute;tiez victime
d'une panne de disque catastrophique, ou -- pire
encore&nbsp;!&nbsp;-- si un cracker nettoyait votre disque sans
vergogne. Ce n'est pas si improbable&nbsp;; j'ai correspondu avec
un bon nombre de gens plac&eacute;s dans une telle situation.
J'exhorte les utilisateurs sens&eacute;s de Linux de sortir acheter
un p&eacute;riph&eacute;rique de sauvegarde, de planifier leurs
sauvegardes dans un emploi du temps digne de ce nom et de <em>s'y
conformer</em>. En ce qui me concerne, je me sers d'un disque
d&eacute;di&eacute; sur une deuxi&egrave;me machine, et
r&eacute;guli&egrave;rement je fais un mirroir de mon
r&eacute;pertoire personnel par le r&eacute;seau. Pour plus
d'information sur la planification des sauvegardes, lisez Frisch
(1995) (voir la section <a href="#sec-credits">Bibliographie et
remerciements</a>).</p>
<p>En l'absence de sauvegardes, que faire (en fait, m&ecirc;me en
pr&eacute;sence de sauvegardes&nbsp;: dans le cas de donn&eacute;es
importantes, la ceinture et les bretelles, ce n'est pas du
luxe)&nbsp;?</p>
<p>Essayez de donner aux fichiers importants les droits 440 (ou
moins)&nbsp;: ne pas vous laisser les droits en &eacute;criture
provoque une demande de confirmation explicite de <code>rm</code>
avant la destruction (mais si je veux supprimer
r&eacute;cursivement un r&eacute;pertoire avec <code>rm -r</code>,
j'interromprai le programme d&egrave;s la premi&egrave;re ou
deuxi&egrave;me demande de confirmation pour relancer la commande
avec <code>rm -rf</code>).</p>
<p>Un bon truc, pour les fichiers importants, est de cr&eacute;er
un lien physique vers eux dans un r&eacute;pertoire cach&eacute;.
J'ai entendu parler d'un administrateur syst&egrave;me qui,
p&eacute;riodiquement, supprimait accidentellement
<code>/etc/passwd</code> (et par l&agrave;-m&ecirc;me
d&eacute;truisait &agrave; moiti&eacute; le syst&egrave;me). Un des
rem&egrave;des fut de lancer en tant que <em>root</em> quelque
chose comme&nbsp;:</p>
<blockquote>
<pre>
<code># mkdir /.backup
# ln /etc/passwd /.backup
</code>
</pre></blockquote>
<p>Il est alors assez difficile de supprimer compl&egrave;tement le
contenu du fichier&nbsp;: si vous dites</p>
<blockquote>
<pre>
<code># rm /etc/passwd
</code>
</pre></blockquote>
<p>alors</p>
<blockquote>
<pre>
<code># ln /.backup/passwd /etc
</code>
</pre></blockquote>
<p>permettra de le r&eacute;cup&eacute;rer. Naturellement, cela ne
couvre pas le cas o&ugrave; vous avez &eacute;cras&eacute; le
contenu du fichier par un autre fichier, donc de toutes
fa&ccedil;ons gardez vos sauvegardes.</p>
<p>Dans un syst&egrave;me de fichiers ext2, il et possible
d'utiliser les attributs ext2 dans le but de prot&eacute;ger ses
donn&eacute;es. Ces attributs sont manipul&eacute;s &agrave; l'aide
de la commande <code>chattr</code>. Il y a un attribut &laquo;
ajout seulement &raquo; (<em>append-only</em>)&nbsp;: il est
possible d'ajouter des donn&eacute;es &agrave; un fichier ayant cet
attribut, mais pas de le supprimer, et le contenu du fichier ne
peut pas &ecirc;tre &eacute;cras&eacute;. Si un r&eacute;pertoire a
cet attribut, tous les fichiers et r&eacute;pertoires qu'il
contient peuvent &ecirc;tre normalement modifi&eacute;s, mais aucun
fichier ne peut &ecirc;tre supprim&eacute;. Cet attribut peut
&ecirc;tre plac&eacute; en tapant</p>
<blockquote>
<pre>
<code>$ chattr +a FICHIER...
</code>
</pre></blockquote>
<p>Il existe aussi un attribut &laquo; immuable &raquo;
(<em>immutable</em>), qui ne peut &ecirc;tre plac&eacute; ou
retir&eacute; qu'en tant que <em>root</em>. Un fichier ou
r&eacute;pertoire ayant cet attribut ne peut &ecirc;tre ni
modifi&eacute;, ni supprim&eacute;, ni renomm&eacute;, ni se faire
ajouter un lien (physique). Il peut &ecirc;tre plac&eacute; comme
suit&nbsp;:</p>
<blockquote>
<pre>
<code># chattr +i FICHIER...
</code>
</pre></blockquote>
<p>Ext2fs fournit &eacute;galement l'attribut &laquo;
r&eacute;cup&eacute;rable &raquo; (<em>undeletable</em>, option
<code>+u</code> de <code>chattr</code>). Si un fichier ayant cet
attribut est supprim&eacute;, mais pas r&eacute;ellemnt
r&eacute;utilis&eacute;, il est d&eacute;plac&eacute; vers un
&laquo; endroit s&ucirc;r &raquo; afin d'&ecirc;tre supprim&eacute;
plus tard. H&eacute;las, cette fonctionnalit&eacute; n'est pas
encore implant&eacute;e dans les noyaux courants&nbsp;; et bien
que, par la pass&eacute;, il y ait eu un peu d'int&eacute;r&ecirc;t
concernant une implantation &eacute;ventuelle, elle n'est pas
(&agrave; ma connaissance) disponible pour les noyaux actuels.</p>
<p>Certains d&eacute;fendent l'id&eacute;e de faire de
<code>rm</code> un alias ou une fonction du gestionnaire de
commandes qui ex&eacute;cute en fait <code>rm -i</code> (qui
demande confirmation pour <em>tous</em> les fichiers &agrave;
supprimer). En effet, certaines versions de la distribution
<a href="http://www.redhat.com/">Red Hat</a> le font par
d&eacute;faut pour tous les utilisateurs, y compris <em>root</em>.
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&eacute;rent, ou simplement une autre machine, o&ugrave; votre
fonction <code>rm</code> n'existera pas. Si vous vous attendez
&agrave; une confirmation, il est assez facile d'oublier o&ugrave;
vous &ecirc;tes et sp&eacute;cifier un peu trop de fichiers
&agrave; supprimer. De m&ecirc;me, les divers scripts et programmes
servant &agrave; remplacer <code>rm</code> sont, &agrave; mon
humble avis, tr&egrave;s dangereux.</p>
<p>Une solution un peu meilleure serait de commencer &agrave;
utiliser un paquetage qui manipulerait une destruction &laquo;
recyclable &raquo; en fournissant une commande qui ne s'appellerait
pas <code>rm</code>. Pour plus de d&eacute;tails, voir Peek <i>et
al</i> (1993) (voir la section <a href="#sec-credits">Bibliographie
et remerciements</a>). Cette solution a cependant
l'inconv&eacute;nient d'encourager les utilisateurs &agrave; avoir
une attitude nonchalante vis-&agrave;-vis de la destruction, au
lieu de l'attitude circonspecte qui est souvent n&eacute;cessaire
sous Unix.</p>
<h2><a name="s3">3. &Agrave; quel taux de
r&eacute;cup&eacute;ration puis-je m'attendre&nbsp;?</a></h2>
<p>&Ccedil;a d&eacute;pend. Parmi les probl&egrave;mes concernant
la r&eacute;cup&eacute;ration de fichiers dans un syst&egrave;me
d'exploitation de haute qualit&eacute;, multi-t&acirc;ches et
multi-utilisateurs comme Linux, il se trouve que vous ne savez
jamais quand quelqu'un veut &eacute;crire sur le disque. Donc,
quand le syst&egrave;me d'exploitation re&ccedil;oit l'ordre de
supprimer un fichier, il suppose libres les blocs utilis&eacute;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&eacute;n&eacute;ral d'Unix&nbsp;: le noyau et les outils
associ&eacute;s supposent que les utilisateurs ne sont pas des
idiots). En g&eacute;n&eacute;ral, plus votre machine est
utilis&eacute;e, moins vous avez de chances de
r&eacute;cup&eacute;rer vos fichiers avec succ&egrave;s.</p>
<p>De plus, la fragmentation du disque peut affecter la
facilit&eacute; de r&eacute;cup&eacute;ration. Si la partition
contenant les fichiers supprim&eacute;s est tr&egrave;s
fragment&eacute;e, vous avez peu de chances de pouvoir lire un
fichier entier.</p>
<p>Si votre machine, comme la mienne, est effectivement une station
destin&eacute;e &agrave; un seul utilisateur, et que vous
n'utilisiez pas intensivement le disque au moment fatal de la
destruction, je m'attendrais &agrave; un taux de
r&eacute;cup&eacute;ration du m&ecirc;me ordre de grandeur que
d&eacute;crit pr&eacute;c&eacute;demment. J'ai
r&eacute;cup&eacute;r&eacute; presque 94 % des fichiers, intacts
(et il s'agissait de fichiers binaires, notez bien). Si vous
obtenez plus de 80 %, vous pouvez &ecirc;tre plut&ocirc;t content
de vous.</p>
<h2><a name="s4">4. Bon, alors comment je r&eacute;cup&egrave;re un
fichier&nbsp;?</a></h2>
<p>La proc&eacute;dure consiste principalement en la recherche de
donn&eacute;es dans le p&eacute;riph&eacute;rique de la partition
en mode caract&egrave;re, et en le fait de la rendre &agrave;
nouveau visible par le syst&egrave;me d'exploitation. Il y a
principalement deux mani&egrave;res de le faire&nbsp;: la
premi&egrave;re consiste &agrave; modifier le syst&egrave;me de
fichier existant de telle fa&ccedil;on que les inodes
supprim&eacute;s aient leur indicateur &laquo; supprim&eacute;
&raquo; retir&eacute;, et esp&eacute;rer que les donn&eacute;es
retombent comme par magie &agrave; leur place. L'autre
m&eacute;thode, plus s&ucirc;re mais plus lente, est de rechercher
o&ugrave; se trouvent les donn&eacute;es dans la partition et de
les &eacute;crire dans un nouveau fichier.</p>
<p>Vous devez suivre plusieurs &eacute;tapes avant de commencer
votre tentative de r&eacute;cup&eacute;ration&nbsp;; voir les
sections <a href="#sec-umount">D&eacute;monter le syst&egrave;me de
fichiers</a>, <a href="#sec-prep-chg">Pr&eacute;parer la
modification directe des inodes</a> et <a href=
"#sec-prep-wrt">Pr&eacute;parer l'&eacute;criture &agrave; un autre
endroit</a> pour plus de d&eacute;tails. Pour d&eacute;couvrir
comment r&eacute;cup&eacute;rer r&eacute;ellement vos fichiers,
voir les sections <a href="#sec-finding">Trouver les inodes
supprim&eacute;s</a>, <a href="#sec-obtain">Obtenir des
d&eacute;tails sur les inodes</a>, <a href=
"#sec-recover">R&eacute;cup&eacute;rer des blocs de
donn&eacute;es</a> et <a href="#sec-modify">Modifier les inodes
directement</a>.</p>
<h2><a name="sec-umount"></a> <a name="s5">5. D&eacute;monter le
syst&egrave;me de fichiers</a></h2>
<p>Quelle que soit la m&eacute;thode que vous choisissiez, la
premi&egrave;re &eacute;tape consiste &agrave; d&eacute;monter le
syst&egrave;me de fichiers contenant les fichiers supprim&eacute;s.
Je vous conseille fortement de r&eacute;fr&eacute;ner toute envie
de bricoler un syst&egrave;me de fichiers mont&eacute;. Cette
&eacute;tape doit &ecirc;tre effectu&eacute;e <em>le plus t&ocirc;t
possible</em>, d&egrave;s que vous vous &ecirc;tes rendu compte que
les fichiers sont supprim&eacute;s.</p>
<p>La m&eacute;thode la plus simple est la suivante&nbsp;: en
supposant que les fichiers supprim&eacute;s soient dans la
partition <code>/usr</code>, tapez&nbsp;:</p>
<blockquote>
<pre>
<code># umount /usr
</code>
</pre></blockquote>
<p>Vous pouvez cependant avoir besoin de garder certaines
donn&eacute;es disponibles dans <code>/usr</code>. Dans ce cas,
remontez-le en mode lecture seule&nbsp;:</p>
<blockquote>
<pre>
<code># mount -o ro,remount /usr
</code>
</pre></blockquote>
<p>Si les fichiers supprim&eacute;s &eacute;taient dans la
partition racine, vous devrez ajouter une option <code>-n</code>,
afin d'emp&ecirc;cher que l'op&eacute;ration de montage ne
d&eacute;clenche une &eacute;criture dans
<code>/etc/mtab</code>&nbsp;:</p>
<blockquote>
<pre>
<code># mount -n -o ro,remount /
</code>
</pre></blockquote>
<p>Ind&eacute;pendamment de tout cela, il est possible qu'un autre
processus utilise &agrave; ce moment-l&agrave; ce syst&egrave;me de
fichier (ce qui fera &eacute;chouer le montage avec une erreur du
genre <em>resource busy</em>). Il y a un programme qui peut envoyer
un signal &agrave; tout processus utilisant un fichier ou point de
montage donn&eacute;&nbsp;: c'est <code>fuser</code>. Pour la
partition <code>/usr</code>, essayez ceci&nbsp;:</p>
<blockquote>
<pre>
<code># fuser -v -m /usr
</code>
</pre></blockquote>
<p>Cela aura pour effet d'afficher la liste des processus
concern&eacute;s. En admettant qu'aucun d'entre eux n'est vital,
vous pouvez taper</p>
<blockquote>
<pre>
<code># fuser -k -v -m /usr
</code>
</pre></blockquote>
<p>afin d'envoyer &agrave; chaque processus un <code>SIGKILL</code>
(qui le tuera d'autorit&eacute;), ou, par exemple,</p>
<blockquote>
<pre>
<code># fuser -k -TERM -v -m /usr
</code>
</pre></blockquote>
<p>pour envoyer plut&ocirc;t &agrave; chacun un
<code>SIGTERM</code> (qui priera le processus de terminer
proprement).</p>
<h2><a name="sec-prep-chg"></a> <a name="s6">6. Pr&eacute;parer la
modification directe des inodes</a></h2>
<p>Mon conseil&nbsp;? Ne faites pas &ccedil;a. Je ne pense vraiment
pas qu'il soit raisonnable d'esp&eacute;rer un r&eacute;sultat en
jouant avec un syst&egrave;me de fichiers &agrave; un si bas
niveau. Du reste, vous ne pourrez r&eacute;cup&eacute;rer de
fa&ccedil;on fiable que les 12 premiers blocs de chaque fichier.
Donc, si vous avez des fichiers longs &agrave;
r&eacute;cup&eacute;rer, vous devrez de toute fa&ccedil;on utiliser
l'autre m&eacute;thode (mais lisez tout de m&ecirc;me la section
<a href="#sec-easier">Cela va-t-il se simplifier dans
l'avenir~?</a> pour plus d'information).</p>
<p>Si vous sentez que vous devez le faire de cette mani&egrave;re,
je vous conseille de copier les donn&eacute;es de la partition en
mode caract&egrave;re dans une autre partition, puis monter le tout
en utilisant le p&eacute;riph&eacute;rique boucle (<em>loopback
device</em>)&nbsp;:</p>
<blockquote>
<pre>
<code># cp /dev/hda5 /root/working
# mount -t ext2 -o loop /root/working /mnt
</code>
</pre></blockquote>
<p>(Notez que les anciennes versions de <code>mount</code> peuvent
avoir des probl&egrave;mes pour faire cela. Si votre
<code>mount</code> ne fonctionne pas, je vous recommande fortement
de vous procurer la derni&egrave;re version, ou tout au moins la
version 2.7, car plusieurs versions plus anciennes ont de graves
probl&egrave;mes de s&eacute;curit&eacute;).</p>
<p>Le but de la manoeuvre est que, quand vous aurez
enti&egrave;rement d&eacute;truit le syst&egrave;me de fichiers (ce
que vous ferez tr&egrave;s probablement), il ne vous restera plus
qu'&agrave; copier la partition dans l'autre sens et repartir
&agrave; nouveau.</p>
<h2><a name="sec-prep-wrt"></a> <a name="s7">7. Pr&eacute;parer
l'&eacute;criture &agrave; un autre endroit</a></h2>
<p>Vous devez vous assurer d'avoir quelque part une partition de
secours. Esp&eacute;rons-le, votre syst&egrave;me a plusieurs
partitions&nbsp;: peut-&ecirc;tre une racine, une
<code>/usr</code>, et une <code>/home</code>. Avec tout ce choix,
aucun probl&egrave;me&nbsp;: cr&eacute;ez simplement un nouveau
r&eacute;pertoire dans l'une d'entre elles.</p>
<p>Si vous n'avez qu'une partition racine dans laquelle vous
fourrez tout, &ccedil;a risque d'&ecirc;tre un poil plus
d&eacute;licat. Peut-&ecirc;tre avez-vous une partition MS-DOS ou
Windows que vous pourriez utiliser&nbsp;? Ou vous avez le
gestionnaire <em>ramdisk</em> dans votre noyau, peut-&ecirc;tre en
module&nbsp;? Pour utiliser le <em>ramdisk</em> (en supposant que
votre noyau soit plus r&eacute;cent que 1.3.48), tapez les
commandes suivantes&nbsp;:</p>
<blockquote>
<pre>
<code># dd if=/dev/zero of=/dev/ram0 bs=1k count=2048
# mke2fs -v -m 0 /dev/ram0 2048
# mount -t ext2 /dev/ram0 /mnt
</code>
</pre></blockquote>
<p>Cela a pour effet de cr&eacute;er un volume <em>ramdisk</em> de
2 Mo, et de le monter en <code>/mnt</code>.</p>
<p>Un petit mot d'avertissement&nbsp;: si vous utilisez
<code>kerneld</code> (ou son rempla&ccedil;ant <code>kmod</code>
avec les noyaux 2.2.x et les derniers 2.1.x) pour charger et
d&eacute;charger automatiquement les modules du noyau, alors ne
d&eacute;montez pas le <em>ramdisk</em> tant que vous n'avez pas
copi&eacute; tous les fichiers qu'il contient sur un support non
volatile. Une fois que vous l'aurez d&eacute;mont&eacute;,
<code>kerneld</code> suppose qu'il peut d&eacute;charger le module
(apr&egrave;s la p&eacute;riode d'attente habituelle), et,
d&egrave;s qu'il l'a fait, la m&eacute;moire est
r&eacute;utilis&eacute;e par d'autres &eacute;l&eacute;ments du
noyau, causant la perte irr&eacute;m&eacute;diable des heures de
travail que vous aurez pass&eacute;es &agrave;
r&eacute;cup&eacute;rer soigneusement vos donn&eacute;es.</p>
<p>Si vous avez un lecteur Zip, Jaz, ou LS-120, ou quelque chose
d'&eacute;quivalent, il s'agit probablement d'une bonne place pour
une partition de secours. Sinon, il faudra faire avec les
disquettes.</p>
<p>Une autre chose dont vous devriez avoir besoin est un programme
capable de lire les donn&eacute;es n&eacute;cessaires en plein
milieu du p&eacute;riph&eacute;rique contenant la partition.
&Agrave; la rigueur, <code>dd</code> pourrait le faire, mais pour
lire &agrave; partir de, disons, 600 Mo dans une partition de 800
Mo, <code>dd</code> tient &agrave; lire les 600 premiers
m&eacute;gaoctets, quitte &agrave; les ignorer, et il va y passer
un temps non n&eacute;gligeable, m&ecirc;me sur des disques
rapides. Pour &eacute;viter cela, j'ai &eacute;crit un programme
qui peut se positionner en plein milieu de la partition. Il
s'appelle <code>fsgrab</code>&nbsp;; vous pouvez trouver le
paquetage des sources sur <a href=
"http://pobox.com/~aaronc/tech/fsgrab-1.2.tar.gz">ma page</a>, ou
sur <a href=
"http://metalab.unc.edu/pub/Linux/utils/file/">Metalab</a> (et ses
miroirs). Si vous souhaitez utiliser cette m&eacute;thode, la suite
de ce mini-HOWTO suppose que vous avez <code>fsgrab</code>.</p>
<p>Si aucun des fichiers que vous voulez r&eacute;cup&eacute;rer
n'occupe plus de 12 blocs (o&ugrave; un bloc occupe habituellement
un kilooctet), alors vous n'aurez pas besoin de
<code>fsgrab</code>.</p>
<p>Si vous avez besoin de <code>fsgrab</code> mais n'en voulez pas,
il est fort simple de traduire une ligne de commande avec
<code>fsgrab</code> en une avec <code>dd</code>. Si on a</p>
<blockquote><code>fsgrab -c <em>count</em> -s <em>skip</em>
<em>device</em></code></blockquote>
<p>alors la commande <code>dd</code> correpondante (et
g&eacute;n&eacute;ralement beaucoup plus lente) est</p>
<blockquote><code>dd bs=1k if=<em>device</em> count=<em>count</em>
skip=<em>skip</em></code></blockquote>
<p>Je dois vous avertir que, bien que <code>fsgrab</code> ait
parfaitement fonctionn&eacute; pour moi, je ne puis prendre aucune
responsabilit&eacute; sur son comportement. C'&eacute;tait vraiment
une bidouille rapide et sale pour arriver &agrave; mes fins. Pour
plus de d&eacute;tails sur l'absence de garantie, consultez la
section <em>No Warranty</em> dans le fichier <code>COPYING</code>
inclus dans la distribution (li s'agit de la GPL, la licence
publique g&eacute;n&eacute;rale GNU).</p>
<h2><a name="sec-finding"></a> <a name="s8">8. Trouver les inodes
supprim&eacute;s</a></h2>
<p>L'&eacute;tape suivante consiste &agrave; demander au
syst&egrave;me de fichiers quels inodes ont &eacute;t&eacute;
r&eacute;cemment lib&eacute;r&eacute;s. C'est une t&acirc;che que
vous pouvez accomplir avec <code>debugfs</code>. Lancez
<code>debugfs</code> avec le nom du p&eacute;riph&eacute;rique sur
lequel le syst&egrave;me de fichiers r&eacute;side&nbsp;:</p>
<blockquote>
<pre>
<code># debugfs /dev/hda5
</code>
</pre></blockquote>
<p>Si vous souhaitez modifier les inodes directement, ajoutez une
option <code>-w</code> de mani&egrave;re &agrave; activer
l'&eacute;criture sur le syst&egrave;me de fichiers&nbsp;:</p>
<blockquote>
<pre>
<code># debugfs -w /dev/hda5
</code>
</pre></blockquote>
<p>La commande <code>debugfs</code> permettant de trouver les
inodes d&eacute;truits est <code>lsdel</code>. Donc, tapez la
commande suivante &agrave; l'invite&nbsp;:</p>
<blockquote>
<pre>
<code>debugfs:  lsdel
</code>
</pre></blockquote>
<p>Apr&egrave;s moult grincements et g&eacute;missements du disque,
une longue liste est envoy&eacute;e par un <em>pipe</em> &agrave;
votre <em>pager</em> favori (la valeur de <code>$PAGER</code>).
Maintenant vous aurez envie d'en sauver une copie autre part. Si
vous avez <code>less</code>, vous pouvez taper <code>-o</code>
suivi du nom du fichier qui devra contenir le r&eacute;sultat.
Sinon, vous devrez vous arranger pour envoyer la sortie ailleurs.
Essayez ceci&nbsp;:</p>
<blockquote>
<pre>
<code>debugfs:  quit
# echo lsdel | debugfs /dev/hda5 &gt; lsdel.out
</code>
</pre></blockquote>
<p>Maintenant, d'apr&egrave;s la date et l'heure de la suppression,
la taille, le type et les indications num&eacute;riques des
permissions et propri&eacute;taire, vous devez deviner quelles
inodes supprim&eacute;s vous voulez. Avec un peu de chance, vous
les trouverez tout de suite parce c'est le gros paquet que vous
avez supprim&eacute; il y a &agrave; peine cinq minutes. Sinon,
prenez bien garde en allant p&ecirc;cher dans la liste.</p>
<p>Je vous sugg&egrave;re, autant que possible, d'imprimer la liste
des inodes que vous voulez r&eacute;cup&eacute;rer. Cela vous
facilitera nettement la vie.</p>
<h2><a name="sec-obtain"></a> <a name="s9">9. Obtenir des
d&eacute;tails sur les inodes</a></h2>
<p><code>debugfs</code> a une commande <code>stat</code>, qui
imprime des d&eacute;tails sur un inode. Utilisez la commande pour
chacun des inodes de votre liste &agrave; r&eacute;cup&eacute;rer.
Par exemple, si vous &ecirc;tes int&eacute;ress&eacute; par l'inode
num&eacute;ro 148003, essayez ceci&nbsp;:</p>
<blockquote>
<pre>
<code>debugfs:  stat &lt;148003&gt;
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
</code>
</pre></blockquote>
<p>Si vous avez de nombreux fichiers &agrave;
r&eacute;cup&eacute;rer, vous souhaiterez automatiser tout cela. En
suposant que votre liste (d'apr&egrave;s <code>lsdel</code>)
d'inodes &agrave; r&eacute;cup&eacute;rer est dans
<code>lsdel.out</code>, essayez ceci&nbsp;:</p>
<blockquote>
<pre>
<code># cut -c1-6 lsdel.out | grep "[0-9]" | tr -d " " &gt; inodes
</code>
</pre></blockquote>
<p>Ce nouveau fichier <code>inodes</code> contient uniquement les
num&eacute;ros des inodes &agrave; r&eacute;cup&eacute;rer,
&agrave; raison d'un par ligne. On le sauvegarde parce qu'il va
nous &ecirc;tre s&ucirc;rement tr&egrave;s utile par la suite. Il
ne vous reste plus qu'&agrave; taper&nbsp;:</p>
<blockquote>
<pre>
<code># sed 's/^.*$/stat &lt;\0&gt;/' inodes | debugfs /dev/hda5 &gt; stats
</code>
</pre></blockquote>
<p>et <code>stats</code> contient la sortie de toutes les commandes
<code>stat</code>.</p>
<h2><a name="sec-recover"></a> <a name="s10">10.
R&eacute;cup&eacute;rer les blocs de donn&eacute;es</a></h2>
<p>Cette partie est soit tr&egrave;s facile, soit nettement moins,
selon que les fichiers que vous essayez de r&eacute;cup&eacute;rer
occupent moins ou plus de 12 blocs.</p>
<h2><a name="ss10.1">10.1 Les fichiers courts</a></h2>
<p>Si le fichier n'occupait pas plus de 12 blocs, alors les
num&eacute;ros de blocs o&ugrave; sont situ&eacute;es toutes ses
donn&eacute;es sont &eacute;crits dans l'inode&nbsp;: vous pouvez
les lire directement sur la sortie de <code>stat</code>
correspondant &agrave; l'inode. De surcro&icirc;t,
<code>debugfs</code> a une commande qui automatise cette
t&acirc;che. Pour reprendre l'exemple
pr&eacute;c&eacute;dent&nbsp;:</p>
<blockquote>
<pre>
<code>debugfs:  stat &lt;148003&gt;
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
</code>
</pre></blockquote>
<p>Ce fichier a six blocs. Puisqu'il est en-dessous de la limite
des 12, nous demandons &agrave; <code>debugfs</code>
d'&eacute;crire le fichier dans un nouvel endroit, comme par
exemple <code>/mnt/recovered.000</code>&nbsp;:</p>
<blockquote>
<pre>
<code>debugfs:  dump &lt;148003&gt; /mnt/recovered.000
</code>
</pre></blockquote>
<p>Bien s&ucirc;r, on peut faire &ccedil;a aussi avec
<code>fsgrab</code>&nbsp;; je le montre ici en guise d'exemple
d'utilisation&nbsp;:</p>
<blockquote>
<pre>
<code># fsgrab -c 2 -s 594810 /dev/hda5 &gt; /mnt/recovered.000
# fsgrab -c 4 -s 594814 /dev/hda5 &gt;&gt; /mnt/recovered.000
</code>
</pre></blockquote>
<p>Que ce soit avec <code>debugfs</code> ou avec
<code>fsgrab</code>, il y aura un peu de d&eacute;chet &agrave; la
fin de <code>/mnt/recovered.000</code>, mais ce n'est pas
tr&egrave;s important. Si vous voulez vous en d&eacute;barrasser,
la m&eacute;thode la plus simple est de prendre le champ
<code>Size</code> de l'inode, et le brancher sur l'option
<code>bs</code> d'une ligne de commande <code>dd</code>.</p>
<blockquote>
<pre>
<code># dd count=1 if=/mnt/recovered.000 of=/mnt/resized.000 bs=6065
</code>
</pre></blockquote>
<p>Bien s&ucirc;r, il est possible qu'un ou plusieurs blocs
o&ugrave; &eacute;tait &eacute;crit votre fichier aient
&eacute;t&eacute; &eacute;cras&eacute;s. Si c'est le cas, pas de
chance&nbsp;: le bloc est mort et enterr&eacute; (rendez-vous
compte, si seulement vous aviez d&eacute;mont&eacute; plus
t&ocirc;t&nbsp;!).</p>
<h2><a name="ss10.2">10.2 Les fichiers plus longs</a></h2>
<p>Les probl&egrave;mes apparaissent lorsque le fichier tient sur
plus de 12 blocs de donn&eacute;es. Ici, il vaut mieux en savoir un
peu sur la mani&egrave;re dont sont structur&eacute;s les
syst&egrave;mes de fichiers Unix. Les donn&eacute;es du fichier
sont stock&eacute;es dans des unit&eacute;s appel&eacute;es &laquo;
blocs &raquo;. Ces blocs peuvent &ecirc;tre num&eacute;rot&eacute;s
s&eacute;quentiellement. Un fichier a &eacute;galement un &laquo;
inode &raquo;, o&ugrave; sont plac&eacute;es des informations
telles que propri&eacute;taire, permissions ou type. Comme les
blocs, les inodes sont num&eacute;rot&eacute;s
s&eacute;quentiellement, bien que la s&eacute;quence soit
diff&eacute;rente. Une entr&eacute;e de r&eacute;pertoire consiste
en un nom de fichier associ&eacute; &agrave; un num&eacute;ro
d'inode.</p>
<p>Mais, si on en restait l&agrave;, le noyau ne saurait toujours
pas trouver les donn&eacute;es correspondant &agrave; une
entr&eacute;e de r&eacute;pertoire. Ainsi l'inode indique
&eacute;galement l'endroit o&ugrave; se trouvent les blocs de
donn&eacute;es du fichier, comme suit&nbsp;:</p>
<ul>
<li>Les num&eacute;ros de blocs des 12 premiers blocs sont
indiqu&eacute;s directement dans l'inode (on les appelle parfois
<em>blocs directs</em>)&nbsp;;</li>
<li>L'inode contient le num&eacute;ro de bloc d'un <em>bloc
indirect</em>. Un bloc indirect contient les num&eacute;ros de bloc
de 256 blocs de donn&eacute;es additionnels&nbsp;;</li>
<li>L'inode contient le num&eacute;ro de bloc d'un <em>bloc
doublement indirect</em>. Un bloc doublement indirect contient les
num&eacute;ros de bloc de blocs indirects
suppl&eacute;mentaires&nbsp;;</li>
<li>L'inode contient le num&eacute;ro de bloc d'un bloc
<em>triplement indirect</em>. Un bloc triplement indirect contient
les num&eacute;ros de bloc de 256 blocs doublement indirects
suppl&eacute;mentaires.</li>
</ul>
<p>Relisez bien tout &ccedil;a&nbsp;: je sais que c'est
compliqu&eacute;, mais c'est important, aussi.</p>
<p>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'&ecirc;tes pas garanti de pouvoir retrouver les
num&eacute;ros de tous les blocs dont vous avez besoin (sans parler
de leur contenu).</p>
<p>La seule m&eacute;thode que j'aie pu trouver jusqu'ici consiste
&agrave; supposer que le fichier n'est pas fragment&eacute;&nbsp;:
s'il l'est, vous aurez des ennuis. En supposant que le fichier
n'est pas fragment&eacute;, il y a plusieurs dispositions de blocs
de donn&eacute;es, selon le nombre de blocs de donn&eacute;es
utilis&eacute;s par le fichier&nbsp;:</p>
<dl>
<dt><b>0 &agrave; 12</b></dt>
<dd>
<p>les num&eacute;ros de bloc sont indiqu&eacute;s dans l'inode,
comme d&eacute;crit pr&eacute;c&eacute;demment&nbsp;;</p>
</dd>
<dt><b>13 &agrave; 268</b></dt>
<dd>
<p>apr&egrave;s les blocs directs, comptez un pour le bloc
indirect, puis vous avez 256 blocs de donn&eacute;es&nbsp;;</p>
</dd>
<dt><b>269 &agrave; 65804</b></dt>
<dd>
<p>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&eacute;p&eacute;titions de&nbsp;: un
bloc indirect (inutile) et 256 blocs de donn&eacute;es&nbsp;;</p>
</dd>
<dt><b>65805 ou plus</b></dt>
<dd>
<p>la disposition des 65804 premiers blocs est identique &agrave;
ce qui est d&eacute;crit di-dessus. Suivent un bloc triplement
indirect (inutile) et 256 r&eacute;p&eacute;titions d'une
s&eacute;quence &laquo; doublement indirect &raquo;. Chaque
s&eacute;quence doublement indirecte consiste en un bloc doublement
indirect (inutile), suivi de 256 r&eacute;p&eacute;titions
de&nbsp;: un bloc indirect (inutile) et 256 blocs de
donn&eacute;es.</p>
</dd>
</dl>
<p>Bien entendu, m&ecirc;me si ces blocs sont suppos&eacute;s
corrects, rien ne garantit que les donn&eacute;es qu'ils
contiennent sont intactes. De plus, plus le fichier est long, moins
vous avez de chances qu'il ait pu &ecirc;tre &eacute;crit dans le
syst&egrave;me de fichiers sans fragmentation raisonnable (sauf
dans certaines circonstances particuli&egrave;res).</p>
<p>Notez que j'ai suppos&eacute; depuis le d&eacute;but que vos
blocs occupaient la taille de 1024 octets, c'est-&agrave;-dire la
valeur standard. Si vos blocs sont plus grands, une partie des
nombres &eacute;crits plus haut doivent &ecirc;tre chang&eacute;s.
Typiquement, puisque chaque num&eacute;ro de bloc occupe 4 octets,
le nombre de num&eacute;ros de bloc pouvant &ecirc;tre
plac&eacute;s dans chaque bloc indirect est taille_du_bloc/4. Donc,
chaque fois que le nombre 256 appara&icirc;t dans la dicussion qui
pr&eacute;c&egrave;de, remplacez-le par taille_du_bloc/4. Les
limitations &laquo; nombre de blocs requis &raquo; devront
&eacute;galement &ecirc;tre modifi&eacute;es.</p>
<p>Examinons un exemple de r&eacute;cup&eacute;ration de fichier
plus long.</p>
<blockquote>
<pre>
<code>debugfs:  stat &lt;1387&gt;
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
</code>
</pre></blockquote>
<p>Il semble y avoir de bonnes chances pour que ce fichier ne soit
pas fragment&eacute;&nbsp;: de fa&ccedil;on &eacute;vidente, les 12
premiers blocs list&eacute;s dans l'inode (qui sont tous des blocs
de donn&eacute;es) sont contigus. Nous pouvons donc commencer par
r&eacute;cup&eacute;rer ces blocs&nbsp;:</p>
<blockquote>
<pre>
<code># fsgrab -c 12 -s 8314 /dev/hda5 &gt; /mnt/recovered.001
</code>
</pre></blockquote>
<p>Maintenant, le bloc suivant list&eacute; dans l'inode, 8326, est
un bloc indirect, que nous pouvons ignorer. Mais nous nous fions
&agrave; notre intuition qu'il sera suivi de 256 blocs de
donn&eacute;es (du num&eacute;ro 8327 au num&eacute;ro 8582).</p>
<blockquote>
<pre>
<code># fsgrab -c 256 -s 8327 /dev/hda5 &gt;&gt; /mnt/recovered.001
</code>
</pre></blockquote>
<p>Le dernier bloc list&eacute; dans l'inode est le 8583. Notez que
&ccedil;a ressemble toujours bien &agrave; un fichier
contigu&nbsp;: le num&eacute;ro du dernier bloc que nous ayons
&eacute;crit &eacute;tait le 8582, donc 8327 + 255. Ce bloc 8583
est un bloc doublement indirect, que nous pouvons ignorer. Il est
suivi par jusqu'&agrave; 256 r&eacute;p&eacute;titions d'un bloc
indirect (ignor&eacute;) suivi de 256 blocs de donn&eacute;es.
Apr&egrave;s un petit calcul mental, on en d&eacute;duit les
commandes suivantes. Remarquez qu'on saute le bloc doublement
indirect 8583 et le bloc indirect 8584, qui suivent
imm&eacute;diatement (esp&eacute;rons-le) et qu'on commence
directement &agrave; lire les donn&eacute;es depuis le bloc
8585.</p>
<blockquote>
<pre>
<code># fsgrab -c 256 -s 8585 /dev/hda5 &gt;&gt; /mnt/recovered.001
# fsgrab -c 256 -s 8842 /dev/hda5 &gt;&gt; /mnt/recovered.001
# fsgrab -c 256 -s 9099 /dev/hda5 &gt;&gt; /mnt/recovered.001
# fsgrab -c 256 -s 9356 /dev/hda5 &gt;&gt; /mnt/recovered.001
# fsgrab -c 256 -s 9613 /dev/hda5 &gt;&gt; /mnt/recovered.001
# fsgrab -c 256 -s 9870 /dev/hda5 &gt;&gt; /mnt/recovered.001
</code>
</pre></blockquote>
<p>En rassemblant tout, on voit qu'on a &eacute;crit depuis le
d&eacute;but 12 + (7 * 256) blocs, c'est-&agrave;-dire 1804. La
commande &laquo; stat &raquo; nous a indiqu&eacute; pour l'inode un
&laquo; <em>blockcount</em> &raquo; de 3616&nbsp;; mais ces blocs
occupaient malheureusement 512 octets (un reliquat d'Unix), ce que
nous voulons r&eacute;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&eacute;es
&eacute;crit portait le num&eacute;ro 10125. De la m&ecirc;me
fa&ccedil;on que depuis le d&eacute;but, on saute un bloc indirect
(num&eacute;ro 10126)&nbsp;; on peut alors &eacute;crire ces quatre
derniers blocs.</p>
<blockquote>
<pre>
<code># fsgrab -c 4 -s 10127 /dev/hda5 &gt;&gt; /mnt/recovered.001
</code>
</pre></blockquote>
<p>Et maintenant, avec un peu de chance, le fichier complet a
&eacute;t&eacute; r&eacute;cup&eacute;r&eacute; avec
succ&egrave;s.</p>
<h2><a name="sec-modify"></a> <a name="s11">11. Modifier les inodes
directement</a></h2>
<p>Cette m&eacute;thode est apparemment beaucoup plus facile.
Cependant, comme soulign&eacute; plus haut, elle ne peut pas venir
&agrave; bout de fichiers occupant plus de 12 blocs.</p>
<p>Pour chaque inode que vous voulez r&eacute;cup&eacute;rer, vous
devez mettre &agrave; 1 le nombre de liens, et &agrave; 0 la date
de suppression. Cela peut &ecirc;tre fait gr&acirc;ce &agrave; la
commande <code>mi</code> (modifier inode) de <code>debugfs</code>.
Voici un exemple de sortie concernant la modification de l'inode
148003&nbsp;:</p>
<blockquote>
<pre>
<code>debugfs:  mi &lt;148003&gt;
                        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]
</code>
</pre></blockquote>
<p>C'est-&agrave;-dire que je mets &agrave; 0 la date de
suppression et le nombre de liens &agrave; 1, puis j'envoie juste
un retour chariot pour chacun des autres champs. D'accord, ce n'est
pas tr&egrave;s souple si vous avez beaucoup de fichiers &agrave;
r&eacute;cup&eacute;rer, mais je pense que vous pourrez faire face.
Si vous vouliez du velours, il fallait utiliser un &laquo;
syst&egrave;me d'exploitation &raquo; graphique avec une jolie
&laquo; corbeille &raquo;.</p>
<p>&Agrave; propos, le texte de sortie de <code>mi</code> indique
un champ &laquo; cr&eacute;ation &raquo; (<em>creation time</em>).
Il est totalement mensonger (ou en tout cas trompeur)&nbsp;! En
fait, sur un syst&egrave;me de fichiers Unix, vous ne pouvez pas
d&eacute;terminer quand un fichier a &eacute;t&eacute;
cr&eacute;&eacute;. Le champ <code>st_ctime</code> d'une
<code>struct stat</code> fait r&eacute;f&eacute;rence &agrave; la
date de modification de l'inode (<em>inode change time</em>),
c'est-&agrave;-dire la derni&egrave;re fois qu'un quelconque des
d&eacute;tails de l'inode a &eacute;t&eacute; chang&eacute;. Si
finit la lessons d'huy.</p>
<p>Notez que les versions plus r&eacute;centes de
<code>debugfs</code> que celle que j'utilise n'incluent
probablement pas certains des champs de la liste donn&eacute;e plus
haut (typiquement <code>Reserved1</code> et des champs sur les
fragments).</p>
<p>Une fois que vous aurez modifi&eacute; les inodes, vous pourrez
quitter <code>debugfs</code> et taper&nbsp;:</p>
<blockquote>
<pre>
<code># e2fsck -f /dev/hda5
</code>
</pre></blockquote>
<p>L'id&eacute;e est que chacun des fichiers supprim&eacute;s a
&eacute;t&eacute; litt&eacute;ralement &laquo;
d&eacute;-supprim&eacute; &raquo;, mais qu'aucun d'entre eux
n'appara&icirc;t en entr&eacute;e de r&eacute;pertoire. Le
programme <code>e2fsck</code> peut le d&eacute;tecter, et ajoutera
une entr&eacute;e dans le r&eacute;pertoire
<code>/lost+found</code> du syst&egrave;me de fichiers (Donc, si la
partition est normalement mont&eacute;e dans <code>/usr</code>, les
fichiers vont appara&icirc;tre dans <code>/usr/lost+found</code>).
Tout ce qui reste &agrave; faire est de redonner son nom &agrave;
chaque fichier d'apr&egrave;s son contenu, et le remettre &agrave;
sa place dans l'arborescence du syst&egrave;me de fichiers.</p>
<p>Quand vous lancerez <code>e2fsck</code>, vous obtiendrez des
messages d'information, ainsi que des questions &agrave; propos des
probl&egrave;mes &agrave; r&eacute;parer. R&eacute;pondez oui
(<em>yes</em>) partout o&ugrave; vous voyez <em>`summary
information'</em> ou &agrave; chaque r&eacute;f&eacute;rence aux
inodes que vous avez modifi&eacute;s. Tout le reste vous regarde,
bien qu'il soit en g&eacute;n&eacute;ral une bonne id&eacute;e de
r&eacute;pondre oui &agrave; toutes les questions. Lorsque
<code>e2fsck</code> a termin&eacute;, vous pouvez remonter le
syst&egrave;me de fichiers.</p>
<p>En fait, il y a un autre moyen que de demander &agrave;
<code>e2fsck</code> de laisser les fichiers dans
<code>/lost+found</code>&nbsp;: vous pouvez utiliser
<code>debugfs</code> pour cr&eacute;er un lien vers l'inode dans le
syst&egrave;me de fichiers. Utilisez la commande <code>link</code>
de <code>debugfs</code> quand vous avez fini de modifier
l'inode.</p>
<blockquote>
<pre>
<code>debugfs:  link &lt;148003&gt; toto.txt
</code>
</pre></blockquote>
<p>Ceci cr&eacute;e un fichier appel&eacute; <code>toto.txt</code>
dans ce que <code>debugfs</code> suppose &ecirc;tre le
r&eacute;pertoire courant&nbsp;; <code>toto.txt</code> sera votre
fichier. Vous aurez quand m&ecirc;me besoin de lancer
<code>e2fsck</code> pour corriger le <em>`summary
information'</em>, le nombre de blocs, etc.</p>
<h2><a name="sec-easier"></a> <a name="s12">12. Cela va-t-il se
simplifier dans l'avenir&nbsp;?</a></h2>
<p>Oui. En fait, je pense que c'est d&eacute;j&agrave; le cas. Bien
qu'au moment o&ugrave; ces lignes sont &eacute;crites (2
f&eacute;vrier 1999), les noyaux stables actuels (la s&eacute;rie
2.0.x) effacent les blocs indirects, ce n'est plus le cas des
noyaux de d&eacute;veloppement 2.1.x, ni des noyaux stables 2.2.x,
dont le 2.2.1 qui vient d'&ecirc;tre diffus&eacute;&nbsp;; nous
allons voir appara&icirc;tre des distributions &agrave; base de
noyaux 2.2.x d'ici un ou deux mois.</p>
<p>Une fois cette limitation retir&eacute;e des noyaux stables, bon
nombre de mes objections au fait de modifier les inodes &agrave; la
main dispara&icirc;tront. Il sera &eacute;galement possible
d'utiliser la commande <code>dump</code> de <code>debugfs</code>
sur des fichiers longs, et d'utiliser d'autres outils de
r&eacute;cup&eacute;ration.</p>
<h2><a name="s13">13. Existe-t-il des outils qui automatisent le
processus&nbsp;?</a></h2>
<p>En fait, il y en a. H&eacute;las, je crains qu'ils souffrent du
m&ecirc;me probl&egrave;me que la technique de modification
manuelle des inodes&nbsp;: les blocs indirects sont
irr&eacute;cup&eacute;rables. Cependant, selon la
probabilit&eacute; que cela ne soit plus un probl&egrave;me d'ici
peu, &ccedil;a vaut s&ucirc;rement le coup de chercher ces
programmes maintenant.</p>
<p>J'ai &eacute;crit un utilitaire nomm&eacute;
<code>e2recover</code>, qui est essentiellement un enrobage Perl
&agrave; <code>fsgrab</code>. Il fait un effort raisonnable pour
g&eacute;rer les blocs indirects effac&eacute;s, et semble
tr&egrave;s bien fonctionner en l'absence de fragmentation. Il en
profite pour remettre les permissions (et, quand c'est possible, le
propri&eacute;taire) des fichiers r&eacute;cup&eacute;r&eacute;s,
et s'assure m&ecirc;me que les fichiers
r&eacute;cup&eacute;r&eacute;s soient &agrave; la bonne taille.</p>
<p>J'ai initialement &eacute;crit <code>e2recover</code> pour la
toute proche mise &agrave; jour de ce Howto&nbsp;; malheureusement
cela signifie que tous les renseignements utiles sur
<code>e2recover</code> sont aussi pr&eacute;vus pour cette mise
&agrave; jour. En attendant, il devrait s'av&eacute;rer quand
m&ecirc;me utile d&egrave;s maintenant&nbsp;; vous pouvez le
t&eacute;l&eacute;charger depuis <a href=
"http://pobox.com/~aaronc/tech/e2-undel/">ma page</a>, et
prochainement sur Metalab.</p>
<p>Scott D. Heavner est l'auteur de <code>lde</code>, (`Linux Disk
Editor'). <code>lde</code> peut servir aussi bien d'&eacute;diteur
binaire de disque, que d'un &eacute;quivalent de
<code>debugfs</code> pour les syst&egrave;mes ext2 et minix, et
m&ecirc;me pour les syst&egrave;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&eacute;s pour faciliter la
r&eacute;cup&eacute;ration, comme le parcours de la liste des
blocs, et la recherche dans le contenu du disque. Il poss&egrave;de
&eacute;galement une documentation sur les concepts de base des
syst&egrave;mes de fichiers particuli&egrave;rement utile, ainsi
qu'un document expliquant comment l'utiliser afin de
r&eacute;cup&eacute;rer des fichiers supprim&eacute;s. La version
2.4 de <code>lde</code> est disponible sur <a href=
"http://metalab.unc.edu/pub/Linux/system/filesystems/lde-2.4.tar.gz">
Metalab</a> et ses mirroirs, et sur <a href=
"http://www.geocities.com/CapeCanaveral/Lab/7731/lde.html">la page
de son auteur</a>.</p>
<p>Une autre possibilit&eacute; est fournie par le GNU Midnight
Commander, <code>mc</code>. C'est un gestionnaire de fichiers en
plein &eacute;cran, inspir&eacute; autant que je le sache d'un
certain programme MS-DOS couramment d&eacute;sign&eacute; sous le
nom de &laquo; nc &raquo;. <code>mc</code> supporte la souris dans
la console Linux et dans un xterm, et fournit des syst&egrave;mes
de fichiers virtuels qui permettent des trucs du genre de se
d&eacute;placer dans une archive Tar. Parmi ses syst&egrave;mes de
fichiers virtuels, il en est un concernant la
r&eacute;cup&eacute;ration sous Ext2. Tout &ccedil;a semble
tr&egrave;s commode &agrave; manipuler, mais je dois avouer que que
je ne l'ai jamais utilis&eacute; moi-m&ecirc;me -- je
pr&eacute;f&egrave;re les bonnes vieilles commandes <em>shell</em>.
Apparemment il faut configurer le programme avec l'option
<code>--with-ext2undel</code>&nbsp;; vous aurez &eacute;galement
besoin des biblioth&egrave;ques de d&eacute;veloppement et des
fichiers d'en-t&ecirc;te (<em>include</em>) qui viennent avec le
paquetage <code>e2fsprogs</code>. La version fournie par <a href=
"http://www.debian.org/">Debian GNU/Linux</a> est ainsi
compil&eacute;&nbsp;; c'est peut-&ecirc;tre le cas pour d'autres
distributions. Une fois que le programme est compil&eacute;, vous
pouvez y taper <code>cd undel:/dev/hda5/</code>, et obtenir, sous
forme de contenu de r&eacute;pertoire, le catalogue des fichiers
supprim&eacute;s. Comme la plupart des outils actuels de
r&eacute;cup&eacute;ration, il g&egrave;re tr&egrave;s mal les
blocs indirects effac&eacute;s -- la plupart du temps il ne
r&eacute;cup&egrave;re que les 12 premiers Ko des gros
fichiers.</p>
<p>La derni&egrave;re version peut &ecirc;tre
r&eacute;cup&eacute;r&eacute;e depuis <a href=
"ftp://ftp.nuclecu.unam.mx/Midnight/devel">le site ftp
officiel</a>.</p>
<h2><a name="s14">14. Achev&eacute; d'imprimer...</a></h2>
<p>J'ai l'intention de produire des mises &agrave; jour
r&eacute;guli&egrave;res de ce document, tant que j'aurai &agrave;
la fois suffisamment de temps pour le faire et quelque chose
d'int&eacute;ressant &agrave; dire. Ceci signifie que je suis avide
de commentaires de la part de mes lecteurs. Ma r&eacute;daction
peut-elle &ecirc;tre plus claire&nbsp;? Pouvez-vous penser &agrave;
quelque chose qui pourrait rendre l'affaire plus simple&nbsp;?
Existe-t-il un nouvel outil qui puisse faire tout cela
automatiquement&nbsp;?</p>
<p>Quoi qu'il en soit&nbsp;: si vous avez quoi que ce soit &agrave;
dire, &agrave; propos de ce document ou des outils
<code>fsgrab</code> et <code>e2recover</code>, envoyez-moi un mot
&agrave;&nbsp;:</p>
<p><code><a href=
"mailto:aaronc@pobox.com">aaronc@pobox.com</a></code>.</p>
<h2><a name="sec-credits"></a> <a name="s15">15. Remerciements et
bibliographie</a></h2>
<blockquote><em>Si j'ai vu plus loin que d'autres, c'est parce que
j'&eacute;tais hiss&eacute; sur des &eacute;paules de
g&eacute;ants</em> (Isaac Newton)</blockquote>
<p>Une grande partie de ce mini-Howto est d&eacute;riv&eacute;e
d'un article post&eacute; sur le groupe de <em>news</em>
<code><a href=
"news:comp.os.linux.misc">comp.os.linux.misc</a></code> par Robin
Glover <code><a href=
"mailto:swrglovr@met.rdg.ac.uk">swrglovr@met.rdg.ac.uk</a></code>.</p>
<p>Je voudrais remercier Robin de m'avoir gracieusement
autoris&eacute; &agrave; reprendre ses id&eacute;es dans ce
mini-Howto.</p>
<p>Je voudrais &eacute;galement profiter de l'occasion pour
remercier une fois de plus toutes les personnes qui m'ont
contact&eacute; &agrave; propos de ce Howto. Ce sont les
remerciements chaleureux que l'on re&ccedil;oit qui justifient la
peine que l'on se donne.</p>
<p>Quelques r&eacute;f&eacute;rences bibliographiques&nbsp;:</p>
<ul>
<li><b>Frisch</b>, &AElig;leen (1995), <em>Essential System
Administration</em>, second edition, O'Reilly and Associates, Inc.,
ISBN&nbsp;: 1-56592-127-5.</li>
<li><b>Garfinkel</b>, Simson, Daniel <b>Weise</b> et Steven
<b>Strassmann</b> (1994), <em>The Unix-Haters Handbook</em>, IDG
Books, ISBN&nbsp;: 1-56884-203-1. Ce livre est compos&eacute; pour
la plus grande partie de pleurs d'adolescents qui pensent que
<em>leur</em> syst&egrave;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 &eacute;pis de bl&eacute; parmi la paille&nbsp;; par
exemple, la discussion autour de la facilit&eacute; d'effacement de
fichier sous Unix m&eacute;rite qu'on s'y arr&ecirc;te.</li>
<li><b>Glover</b>, Robin (31 Jan 1996), <em>HOW-TO&nbsp;: undelete
linux files (ext2fs/debugfs)</em>, comp.os.linux.misc Usenet
posting.</li>
<li><b>Peek</b>, Jerry, Tim <b>O'Reilly</b>, Mike <b>Loukides</b>
<em>et al</em> (1993), <em>UNIX Power Tools</em>, O'Reilly and
Associates, Inc./Random House, Inc., ISBN&nbsp;:
0-679-79073-X.</li>
</ul>
<h2><a name="s16">16. Bla-bla juridique</a></h2>
<p>Toutes les marques d&eacute;pos&eacute;es sont la
propri&eacute;t&eacute; de leurs auteurs respectifs.
Sp&eacute;cifiquement&nbsp;:</p>
<ul>
<li><em>MS-DOS</em> et <em>Windows</em> sont des marques
d&eacute;pos&eacute;es de <a href=
"http://www.microsoft.com/">Microsoft</a>&nbsp;;</li>
<li><em>UNIX</em> est une marque d&eacute;pos&eacute;e de
<em><a href="http://www.open.org/">the Open
Group</a></em>&nbsp;;</li>
<li><em>Linux</em> est une marque d&eacute;pos&eacute;e de Linus
Torvalds aux USA et dans quelques autres pays.</li>
</ul>
<p>Ce document est Copyright &copy; 1997, 1999 Aaron Crane
<code><a href=
"mailto:aaronc@pobox.com">aaronc@pobox.com</a></code>. Il peut
&ecirc;tre librement et enti&egrave;rement redistribu&eacute;
&agrave; condition d'y inclure toujours la totalit&eacute; de cette
note de copyright, mais ne peut pas &ecirc;tre modifi&eacute; sans
l'autorisation, soit de son auteur, soit du coordinateur du Linux
Documentation Project. Une d&eacute;rogation est cependant
accord&eacute;e dans le cas de la copie de courts extraits sans
modification pour des revues ou une citation&nbsp;; dans ces
circonstances, les sections peuvent &ecirc;tre reproduites
accompagn&eacute;es d'une citation appropri&eacute;e mais sans
cette note de copyright.</p>
<p>L'auteur demande, mais n'exige pas, que des parties souhaitant
vendre des copies de ce document, sur un <em>medium</em> lisible
par un ordinateur ou par un humain, informent de leurs intentions,
soit l'auteur, soit le coordinateur des HOWTO Linux.</p>
<p>Le coordinateur des HOWTO Linux est actuellement Tim Bynum
<code><a href=
"mailto:linux-howto@metalab.unc.edu">linux-howto@metalab.unc.edu</a></code>.</p>
</body>
</html>