Newsgroup: it.comp.os.linux.sys
Titolo: Recupero files

Salve a tutti,
oggi e' capitata anche a me: un colpo sbagliato di "rm" ed ho perso
alcuni files importanti. Dopo le eresie di rito, mano al disco di
boot/root e via con i tentativi di recupero.
A parte due, i piu' grossi [non risultavano neanche come cancellati
nella tabella degli inode], gli altri sono stati recuperati al 100%.
Fortunatamente erano i piu' importanti. Tutto bene quel che finisce
bene, cmq qualche domanda l'avrei.
Le dimensioni del file piu' grosso recuperato, sono di 6025019 bytes.
L'ho trovato diviso su due inode:
1.
debugfs:  Inode: 157090   Type: regular    Mode:  0600   Flags: 0x0
Version: 1User:  1000   Group:  1000   Size: 3704065
File ACL: 0    Directory ACL: 0
Links: 0   Blockcount: 7268
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x3879d8c4 -- Mon Jan 10 14:04:04 2000
atime: 0x3879d8ad -- Mon Jan 10 14:03:41 2000
mtime: 0x38771dad -- Sat Jan  8 12:21:17 2000
dtime: 0x3879d8c4 -- Mon Jan 10 14:04:04 2000
BLOCKS:
[...]
TOTAL: 3634
2.
debugfs:  Inode: 157091   Type: regular    Mode:  0600   Flags: 0x0
Version: 1User:  1000   Group:  1000   Size: 2320954
File ACL: 0    Directory ACL: 0
Links: 0   Blockcount: 4554
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x3879d8c4 -- Mon Jan 10 14:04:04 2000
atime: 0x3879d8ad -- Mon Jan 10 14:03:41 2000
mtime: 0x38771db4 -- Sat Jan  8 12:21:24 2000
dtime: 0x3879d8c4 -- Mon Jan 10 14:04:04 2000
BLOCKS:
[...]
TOTAL: 2277
L' ho recuperato con un semplice "dump" da debugfs, senza incontrare gli
ostacoli descritti nell'Ext2fs Undeletion HOWTO per i files che occupano
piu' di 12 blocchi. Un cat e i file risultanti dal recupero dei due
inode hanno felicemente ricomposto quello originale.
Come mai non ho incontrato difficolta' con la storia dei 12 blocchi?
Forse perche' sono subito corso ai ripari? Fortuna?
Mi piacerebbe approfondire la questione. Potreste indicarmi della
documentazione in materia?
Ringrazio anticipatamente.
P.S.
fathom@ilbarone:~/Store$ [tty2] su
Password:
root@ilbarone:/home/fathom/Store# [tty2] chattr +i ./* ; exit
=)))
Saluti.
-- 
Francesco Toscan                      | WinNT(s):
fathom(at)
penguinpowered.com
          | un frammento per trovarli
http://www.penguinpowered.com/~fathom
 | un frammento per domarli
[In costruzione :(]                   | un frammento per crasharli
ICQ: 26435470                         | e nel bluescreen incatenarli

On Mon, 10 Jan 2000 17:31:01 GMT, Fathom wrote
| Come mai non ho incontrato difficolta' con la storia dei 12 blocchi?
| Forse perche' sono subito corso ai ripari? Fortuna?
Nell' Ext2fs-Undeletion dice che la limitazione dei 12 blocchi era
tipica dei kernel 2.0.x , ma che era stata corretta gia` nei 2.1.x
(quindi presente di serie nei 2.2.x) [cfr paragrafo 12].
  12.  Will this get easier in future?
  Yes.  In fact, I believe it already has.  Kernels in the development
  2.1.x series have not zeroed indirect blocks since more than six
  months ago.  At the beginning of December 1996, there was some talk on
  the linux-kernel mailing-list of producing another 2.0.x production
  kernel that also leaves indirect blocks intact on deletion.  Although
  as of the pre-released versions of kernel 2.0.31 this has not
  happened, I suspect that it is feasible.  Once Linus and the other
  kernel hackers overcome this limitation in the production kernels, a
  lot of my objections to the technique of modifying inodes by hand will
  disappear.  At the very latest, this should happen on the release of
  the 2.2.x kernel series, which (according to historical kernel
  development time-scales) should happen some time in the first quarter
  of 1998.  When this wart is corrected, it will also be possible to use
  the dump command in debugfs on long files.
-- 
 ____      ___              | 3/4 Romulan, 1/4 Vorta. | [70 2E] [71 FF] 
/_  / ___ / _/______ ___ _  | Stirred, not Shaked.    |  - CMOS 
 / /_/ -_) _/ __/ _ `/  ' \ | 
http://zefram.8m.com
    | Lasciate che i concetti 
/___/\__/_//_/  \_,_/_/_/_/ | 
zef...@iol.it
	      | fluiscano liberi - ZC
	- Zefram is on a K6-166 32MB - RH6.0 - Kernel 2.2.12 -


AZz...l'avevo letto + volte pure io il paragrafo 12...ed avevo
capito esattamente il contrario :O Eppure l'ho letto in italiano :)
Rileggendo effettivamente mi chiedo se ero sobrio o meno il giorno del
post.
Grazie :P
