<!doctype linuxdoc system>

<article OPTS="italian">

<title>Linux Ext2fs Undeletion mini-HOWTO
<author>Aaron Crane,
 <tt><htmlurl url="mailto:aaronc@pobox.com" name="aaronc@pobox.com">
 </tt>
<date>v1.3, 2 Febbraio 1999
<abstract>
Immaginate: per gli ultimi tre giorni non avete dormito, non avete mangiato,
non avete nemmeno fatto la doccia. La vostra foga di hacker vi ha finalmente
ricompensato: avete finito il programma che vi porter&agrave; fama 
mondiale. Tutto quello che dovete fare &egrave; farne un tar e metterlo su
Metalab. Oh, e cancellare tutti quei file di backup di Emacs. Quindi date
<tt/rm * &tilde;/.  E, troppo tardi, notate lo spazio di troppo in quel
comando. Avete appena cancellato la vostra  <em/magnum opus/!

Ma ecco l'aiuto. Questo documento vi presenta una discussione su come
recuperare i file cancellati da un filesystem Second Extended. Cos&igrave;,
forse, potrete fare uscire quel programma...
</abstract>

<toc>

<sect>Introduzione

<p>Questo mini-howto &egrave; un tentativo di fornire suggerimenti su come 
recuperare file cancellati da un filesystem ext2. Contiene anche una breve 
discussione su come evitare a priori di cancellare dei file.


La mia intenzione &egrave; che sia utile sicuramente per le persone che abbiano
appena avuto, diciamo, un piccolo incidente con <tt/rm/;, ma spero che venga
letto comunque. Non si sa mai, un giorno queste informazioni vi potrebbero 
salvare la pelle.

Il testo assume una conoscenza di base dei filesystem UNIX in generale, ma 
spero che sia accessibile alla maggior parte degli utenti Linux. Se siete 
dei veri principianti, ho paura che il recupero di file sotto Linux
<em/richieda/ una certa conoscenza tecnica, almeno al momento.

Non potrete recuperare dei file cancellati da un filesystem ext2 senza avere
almeno accesso in lettura al dispositivo fisico in cui il file si trovava. In 
generale, questo significa che dovete essere root, ma alcune distribuzioni
(come la <htmlurl url="http://www.debian.org/" name="Debian GNU/Linux">)
hanno impostato un gruppo <tt/disk/ i cui membri hanno accesso a tali 
dispositivi. Vi serve anche <tt/debugfs/
dal pacchetto <tt/e2fsprogs/, che dovrebbe essere stato installato dalla 
distribuzione che avete.

Perch&eacute; ho scritto questo documento? Pi&ugrave; che altro &egrave; nato 
dalla mia esperienza con un particolarmente stupido e disastroso
comando <tt/rm -r/ da root. Ho cancellato circa 97 file JPEG che mi servivano e non avrei
potuto quasi sicuramente recuperare da altre fonti. Usando alcuni suggerimenti
utili (vedere la sezione <ref id="sec-credits" name="Ringraziamenti e
bibliografia">) e molta testardaggine, ho recuperato 91 file integri. Sono 
riuscito a recuperare almeno delle parti di 5 dei restanti (abbastanza per 
vedere quale era la figura). Solo uno &egrave; andato perso del tutto,
e anche di 
questo sono quasi sicuro che non ne ho persi pi&ugrave; di 1024 byte (anche
se sfortunatamente erano all'inizio del file: e non so niente del formato dei
file JFIF e ho fatto tutto quello che potevo).

Discuter&ograve; pi&ugrave; avanti quale percentuale di recupero ci si
pu&ograve; aspettare per i file cancellati.


<sect1>Revisioni

<p>Le varie revisioni pubbliche di questo documento (e le loro date di 
pubblicazione) sono le seguenti:

<itemize>
<item>v1.0 del 18 Gennaio 1997
<item>v1.1 del 23 Luglio 1997 (vedere la sezione 
<ref id="sec-v1.1" name="Modifiche nella v1.1">)
<item>v1.2 del 4 Agosto 1997 (vedere la sezione 
<ref id="sec-v1.2" name="Modifiche nella v1.2">)
<item>v1.3 del 2 Febbraio 1999 (vedere la sezione 
<ref id="sec-v1.3" name="Modifiche nella v1.3">)
</itemize>

<sect2>Modifiche nella versione 1.1<label id="sec-v1.1">

<p>Quali modifiche sono state fatte in questa versione? Prima di tutto, 
ho corretto il "thinko" nell'esempio del recupero file. Grazie a tutti quelli
che mi hanno scritto: spero di avere imparato ad essere pi&ugrave; attento 
quando scrivo delle interazioni con i programmi.

Seconda cosa, ho riscritto la discussione sullo schema del filesystem UNIX, 
in modo che sia, spero, pi&ugrave; comprensibile. Non ne ero molto contento
all'inizio, e i commenti di alcune persone mi hanno indicato che non era 
chiaro. 

Terzo, ho rimosso il .tar.gz uuencodato di <tt/fsgrab/ che era nel mezzo del 
file. Il programma &egrave; adesso disponibile dal
<url url="http://pobox.com/&tilde;aaronc/tech/fsgrab-1.2.tar.gz"
     name="mio sito web">
e presto dovrebbe arrivare su
<url url="http://metalab.unc.edu/pub/Linux/utils/file/"
     name="Metalab">
(e sui mirror).

Quarta cosa, il documento &egrave; stato tradotto nel linguaggio SGML usato
dal Linux Documentation Project. Questo linguaggio pu&ograve; essere facilmente
convertito in molti altri linguaggi (compreso l'HTML e il LaTeX) per essere 
 visualizzato e  stampato facilmente. Uno dei vantaggi di questa cosa &egrave;
che &egrave; pi&ugrave; facile avere una bella versione cartacea, un'altro 
&egrave; che il documento ha i riferimenti interni e i link ipertestuali 
quando viene visualizzato sul web.


<sect2>Modifiche nella versione 1.2<label id="sec-v1.2">

<p>Questa revisione ha solo delle modifiche incrementali. Consiste 
principalmente di modifiche suggerite dai lettori, una delle quali &egrave;
particolarmente importante.

La prima modifica &egrave; stata suggerita da Egil Kvaleberg
<tt><htmlurl url="mailto:egil@kvaleberg.no" name="egil@kvaleberg.no"></tt>,
che ha fatto notare il comando <tt/dump/ in <tt/debugfs/. Grazie ancora, Egil.

La seconda &egrave; quella di menzionare l'uso di <tt/chattr/ per evitare
di cancellare i file importanti. Grazie ad Herman Sujis
<tt><htmlurl url="mailto:H.P.M.Suijs@kub.nl" name="H.P.M.Suijs@kub.nl"></tt>.

L'abstract &egrave; stato rivisto. Sono stati aggiunti degli URL per le
organizzazioni ed il software. Sono state apportate altre modifiche minori
(compresi alcuni errori di battitura e cose del genere).

<sect2>Modifiche nella versione 1.3<label id="sec-v1.3">

<p>Anche se questa &egrave; la prima versione dopo 17 mesi, &egrave;
stato modificato molto poco. Questa versione corregge solo alcuni piccoli
errori (refusi, URL modificati e cos&igrave; via), ed aggiorna alcune parti
che erano diventate datatissime. Ah, e ho cambiato `Sunsite' in `Metalab'.

Questa versione sar&agrave; l'ultima prima della 2.0, che si spera sar&agrave;
un Howto completo. Sto lavorando su delle modifiche sostanziali che 
giustificheranno un incremento nel numero della versione.

<sect1>Dove si pu&ograve; trovare questo documento

<p>L'ultima versione pubblica del documento dovrebbe essere sempre disponibile
in formato testo nel
<url url="http://metalab.unc.edu/LDP/"
     name="sito del Linux Documentation Project">
(e nei suoi mirror).

L'ultima versione viene anche tenuta sul 
<url url="http://pobox.com/&tilde;aaronc/"
     name="mio sito web">
in diversi formati:

<itemize>
<item><url url="http://pobox.com/&tilde;aaronc/tech/e2-undel/howto.sgml"
           name="sorgente SGML">.
      Il sorgente come l'ho scritto, usando il pacchetto SGML tools.
<item><url url="http://pobox.com/&tilde;aaronc/tech/e2-undel/html/"
           name="HTML">.
      HTML, generato automaticamente dal sorgente SGML.
<item><url url="http://pobox.com/&tilde;aaronc/tech/e2-undel/howto.txt"
           name="Testo puro">.
      Testo puro, anch'esso generato automaticamente dal sorgente SGML.
</itemize>

<sect>Come fare a non cancellare i file

<p>&Egrave; vitale ricordare che linux non &egrave; come l'MS-DOS quando si
parla di recuperare file cancellati. Per l'MS-DOS (e la sua progenie 
bastarda Windows 95) generalmente recuperare un file &egrave; una cosa 
piuttosto semplice - il `sistema operativo' (uso il termine in un'accezione
molto ampia) comprende addirittura anche un programma che automatizza la 
maggior parte del processo. 
Questo non &egrave; il caso di Linux.

Quindi, regola numero uno (il primo comandamento, se volete):

<quote>
<bf/TENETE I BACKUP/
</quote>

in qualsiasi caso. Pensate a tutti i vostri dati; forse, come me, avete
vari anni di email, contatti, programmi, lavori che si sono accumulati
sul vostro computer. Pensate a come vi sentireste se il vostro disco si 
rompesse, o se -- Signore salvaci! -- un cracker vi cancellasse tutto 
l'hard disk. Non &egrave; poi cos&igrave; inconsueto: io sono stato in 
contatto come molte persone in situazioni del genere. Esorto tutti i
Linuxisti di buona volont&agrave; a uscire e comprare un buon mezzo di 
backup, pensare ad una buona policy di backup ed a <em/usarla/. Io
personalmente uso un secondo disco su un'altra macchina, e faccio
un mirror periodico della mia home directory su di esso via ethernet. 
Per altre informazioni su come fare una policy di backup, leggete il 
Frisch (1995) (vedere la sezione
<ref id="sec-credits" name="Bibliografia e Ringraziamenti">).

In mancanza di backup, cosa fare? (o anche in presenza di backup:
se avete dei dati importanti &egrave, meglio andarci coi piedi di 
piombo).

Provate ad impostare i permessi dei file importanti a 440 (o meno):
negarvi il permesso di cancellare dei file implica una conferma 
esplicita prima di cancellarli (io comunque trovo che, se sto cancellando
ricorsivamente una directory con <tt/rm -r/, interrompo il programma alla
prima o seconda richiesta di cancellazione e lo rid&ograve; come 
<tt/rm -rf/).

Un buon trucco per i file selezionati &egrave; crearne un hard link in una directory nascosta.
Ho sentito una storia di un amministratore di sistema che ha cancellato ripetutamente 
<tt>/etc/passwd</tt> per errore (quindi praticamente distruggendo met&agrave; del sistema).
Una delle soluzioni sarebbe stata fare una cosa del genere (da root):

<tscreen><verb>
# mkdir /.backup
# ln /etc/passwd /.backup
</verb></tscreen>

Cancellare tutto il contenuto richiede un po' di sforzo: se dite

<tscreen><verb>
# rm /etc/passwd
</verb></tscreen>

fare

<tscreen><verb>
# ln /.backup/passwd /etc
</verb></tscreen>

la recuperer&agrave;. Certo, non aiuta nel caso in cui abbiate 
sovrascritto il file, quindi tenete comunque dei backup.

Su un filesystem ext2 &egrave; possibile usare degli attributi ext2 per 
proteggere i file. Questi attributi possono essere modificati con il 
comando <tt/chattr/. Esiste un attributo `append-only' (sola
aggiunta): un file  
con questo attributo non puņ essere cancellato, ma possono essere solo
aggiunti dei dati. Se una directory ha questo attributo, qualsiasi file
o directory in essa contenuti puņ essere modificato come il solito, ma non
possono essere cancellati dei file. L'attributo `append-only' si imposta con
il comando

<tscreen><verb>
$ chattr +a FILE...
</verb></tscreen>

C'&egrave; anche un attributo `immutable' (non modificabile), che si pu&ograve; impostare o 
togliere solo da root. Un file o una directory con questo attributo 
non pu&ograve; essere modificato, cancellato, rinominato e non ci si
possono fare hard link. Si imposta cos&igrave;:

<tscreen><verb>
# chattr +i FILE...
</verb></tscreen>

L'ext2fs ha anche l'attributo `undeletable' (non cancellabile) (<tt/+u/ in <tt/chattr/).
L'intenzione &egrave; che se un file con quell'attributo viene cancellato,
invece di essere veramente riutilizzato, viene soltanto spostato in un "posto sicuro" 
per poter essere cancellato in un secondo tempo. Sfortunatamente questa caratteristica
non &egrave; stata ancora implementata nei principali kernel; anche se in 
passato c'&egrave; stato un qualche interesse nella sua implementazione, 
a quanto ne so non &egrave; disponibile per le versioni recenti del kernel.

Alcuni suggeriscono di rendere <tt/rm/ un alias di shell o una funzione che stia per 
<tt/rm -i/ (che chiede conferma su <em/qualsiasi/ file che cancellate). Addirittura la <url url="http://www.redhat.com/" name="distribuzione Red Hat">
lo mette per default a tutti gli utenti, compreso root. Personalmente, non riesco a 
sopportare il software che non funziona da solo, quindi non faccio cos&igrave;. 
C'&egrave; anche il problema che, prima o poi, userete la modalit&agrave; a 
utente singolo, o una shell diversa o addirittura una macchina diversa, 
dove la funzione <tt/rm/ che avete definito non esiste.
Se vi aspettate che vi venga chiesta conferma, &egrave; facile dimenticarsi dove vi 
trovate e specificare troppi file al comando di cancellazione. Ugualmente, i vari script e
i programmi che sostituiscono <tt/rm/ sono, IMHO, molto pericolosi.

Una soluzione leggermente migliore &egrave; cominciare ad usare un pacchetto che 
gestisca la "cancellazione riciclabile" fornendo un comando che non si chiami <tt/rm/.
Per avere ulteriori dettagli su questo argomento, vedere Peek, et al (1993) (vedere la sezione
<ref id="sec-credits" name="Bibliografia e ringraziamenti">). Queste, 
per&ograve; hanno il problema che tendono ad incoraggiare l'utente a non fare 
attenzione quando cancellano dei file, invece che starci molto attenti, come
spesso &egrave; richiesto nei sistemi Unix.

<sect>Che percentuale di recupero mi posso aspettare?

<p>Dipende. Tra i problemi che insorgono nel recupero dei file su un sistema operativo
di alta qualit&agrave;, multitasking e multi-utente come Linux c'&egrave; quello che
non si sa mai quando qualcuno vuole scrivere su disco. Quindi, quando al sistema operativo 
viene detto di cancellare un file, assume che i blocchi usati da quel file sono disponibili
per allocare spazio per un altro file (&egrave; un esempio specifico di un principio generale
di Linux: il kernel e gli strumenti relativi assumono che gli utenti non siano idioti).
In generale, pi&ugrave; viene usata la macchina, meno &egrave; probabile che riusciate a
recuperare con successo i vostri file.

Inoltre, la frammentazione del disco pu&ograve; influire sulla facilit&agrave; di recupero
dei file. Se la partizione che contiene i file cancellati &egrave; molto frammentata, &egrave; 
poco probabile che riusciate a leggere un file intero.

Se la vostra macchina, come la mia, &egrave; effettivamente una workstation a utente singolo, e non stavate
facendo nessuna attivit&agrave; che scrivesse su disco al momento fatale della cancellazione
dei file, potete aspettarvi una percentuale di recupero vicina a quella che ho
indicato prima. Io ne ho recuperati all'incirca il 94&percnt; (ed erano file binari, notare).
Penso che possiate essere contenti con voi stessi se ne riuscite a  recuperare pi&ugrave; 
dell'80&percnt;.

<sect>E allora, come faccio a recuperare un file?

<p>La procedura consiste principalmente nel trovare i dati a basso livello nella partizione, 
e nel renderli di nuovo visibili al sistema operativo. Ci sono principalmente due modi per 
farlo: uno &egrave; modificare il filesystem esistente in modo da rimuovere l'indicazione
di "cancellato" dagli inode dei file in questione, e sperare che i dati ritornino magicamente
 a posto. L'altro metodo, che &egrave; pi&ugrave; sicuro ma pi&ugrave; lento, &egrave; 
capire dove i dati si trovano nella partizione e scriverli in un nuovo file su
un altro sistema.

Ci sono alcuni passi necessari da fare prima di iniziare a cercare di recuperare i dati:
per altri dettagli vedere le sezioni
<ref id="sec-umount" name="Smontare il filesystem">,
<ref id="sec-prep-chg" name="Prepararsi alla modifica diretta degli inode"> e
<ref id="sec-prep-wrt" name="Prepararsi alla scrittura dei dati da qualche altra parte">.
Per sapere come fare in pratica a recuperare i file, vedere le sezioni
<ref id="sec-finding" name="Trovare gli inode cancellati">,
<ref id="sec-obtain" name="Ottenere i dettagli degli inode">,
<ref id="sec-recover" name="Recuperare i blocchi di dati"> e
<ref id="sec-modify" name="Modificare gli inode direttamente">.

<sect>Smontare il filesystem<label id="sec-umount">

<p>Qualsiasi sia il metodo che avete scelto, il primo passo č smontare il filesystem
che contiene i file cancellati. Vi sconsiglio fortemente di andare in qualsiasi modo
a operare su un filesystem montato. Questo passo dovrebbe essere fatto <em/al pi&ugrave;
presto possibile/ dopo che vi siete accorti della cancellazione dei file: prima
fate umount, minore &egrave; la probabilit&agrave; che i vostri file vengano
sovrascritti.

Il metodo pi&ugrave; semplice &egrave; questo: assumendo che i file cancellati
siano nel filesystem  <tt>/usr</tt>, fate

<tscreen><verb>
# umount /usr
</verb></tscreen>

Potete comunque voler mantenere disponibili alcune cose di <tt>/usr</tt>, quindi
montatelo a sola lettura:

<tscreen><verb>
# mount -o ro,remount /usr
</verb></tscreen>

Se i file cancellati erano nella partizione di root, dovrete aggiungere l'opzione
<tt/-n/ per evitare che mount cerchi di scrivere su <tt>/etc/mtab</tt>:

<tscreen><verb>
# mount -n -o ro,remount /
</verb></tscreen>

A parte questo, &egrave; possibile che ci sia un altro processo che stia usando
il filesystem in questione (che far&agrave; fallire l'umount con un errore 
di `Resource busy'). Esiste un programma che manda un segnale a qualsiasi processo
che sta usando un dato file o punto di mount: <tt/fuser/. Provatelo con la 
partizione <tt>/usr</tt>:

<tscreen><verb>
# fuser -v -m /usr
</verb></tscreen>

elencher&agrave; i processi coinvolti. Assumendo che nessuno di essi sia
vitale, potete dare

<tscreen><verb>
# fuser -k -v -m /usr
</verb></tscreen>

per mandare ad ogni processo un <tt/SIGKILL/ (che sicuramente lo uccider&agrave;),
o ad esempio

<tscreen><verb>
# fuser -k -TERM -v -m /usr
</verb></tscreen>

per mandargli un <tt/SIGTERM/ (che normalmente far&agrave; uscire il processo
in maniera pulita).

<sect>Prepararsi alla modifica diretta degli inode<label id="sec-prep-chg">

<p>Il mio consiglio? Non fate cos&igrave;. Non credo che sia una cosa saggia
giocare con un filesystem a livello abbastanza basso da fare funzionare questo
metodo. Questo metodo d&agrave; anche dei
problemi nel senso che si possono recuperare in modo
affidabile solo i primi 12 blocchi di ciascun file, quindi se avete dei file 
lunghi da recuperare dovrete usare l'altro metodo (leggete per&ograve; la 
sezione <ref id="sec-easier" name="Questo metodo diventer&agrave; pi&ugrave;
facile in futuro?"> per altre informazioni).

Se pensate di dover usare questo metodo, il mio consiglio &egrave; di
copiare  
la partizione raw su una partizione diversa, e poi montarla usando il loopback:

<tscreen><verb>
# cp /dev/hda5 /root/working
# mount -t ext2 -o loop /root/working /mnt
</verb></tscreen>

(Notate che delle versioni obsolete di <tt/mount/ possono avere dei
problemi con questo metodo. Se il vostro <tt/mount/ non funziona, il mio
suggerimento &egrave; di aggiornarlo all'ultima versione, o almeno alla 2.7,
dato che alcune versioni molto vecchie hanno dei gravi problemi di sicurezza.)

Usare il loopback significa che se e quando distruggere completamente il
filesystem, tutto quello che dovrete fare &egrave; copiare la partizione
grezza al suo posto e ricominciare.

<sect>Prepararsi alla scrittura dei dati da qualche altra parte<label id="sec-prep-wrt">

<p>Se scegliete questo metodo, dovete assicurarvi di avere da qualche parte 
una partizione di recupero, cio&egrave; un posto in cui scrivere nuove copie
dei file che recuperate.
Magari, avete diverse partizioni sul vostro sistema: forse una di root, una
per <tt>/usr</tt>, e una per <tt>/home</tt>.  Con tutte queste partizioni non 
dovreste avere problema: create semplicemente una nuova directory in una 
di esse.

Se avete solo una partizione di root, ed immagazzinate tutto su quella, 
le cose sono
leggermente pi&ugrave; strane. Forse avete una partizione MS-DOS o Windows
da usare? O avete il driver per il ramdisk nel kernel, forse come modulo?
Per usare il ramdisk (assumendo che abbiate un kernel pi&ugrave; recente
dell'1.3.48), fate cos&igrave;:

<tscreen><verb>
# dd if=/dev/zero of=/dev/ram0 bs=1k count=2048
# mke2fs -v -m 0 /dev/ram0 2048
# mount -t ext2 /dev/ram0 /mnt
</verb></tscreen>

Questo crea un volume di ramdisk di 2MB, e lo monta su <tt>/mnt</tt>.

Un breve avvertimento: se usate <tt/kerneld/ (o il suo sostituto <tt/kmod/
nei kernel 2.2.x e negli ultimi 2.1.x) per caricare e 
scaricare automaticamente i moduli del kernel, allora non montate il
ramdisk finch&eacute; non avete copiato tutti i file che vi si trovano 
su un supporto non volatile. Una volta smontato, <tt/kerneld/ 
assume che pu&ograve; smontare il modulo (dopo il normale periodo di 
attesa), e una volta che ci&ograve; accade, la memoria viene riutilizzata 
da altre parti del kernel, perdendo tutte le ore di fatica che avete fatto per
recuperare i vostri dati.


Se avete uno Zip, un Jaz, un LS-120 o una cosa simile, probabilmente sono una
buona scelta per metterci una partizione di recupero. Altrimenti, dovrete
solo usare i floppy.

L'altra cosa di cui avrete bisogno &egrave; un programma che pu&ograve; leggere
i dati necessari dal mezzo del dispositivo della partizione. Per
iniziare, <tt/dd/ adr&agrave; bene, ma per leggere diciamo, dal
600esimo MB in una partizione da 800 MB, 
<tt/dd/ insiste a leggere ma ad ignorare i primi 600 MB. Questo prende un
tempo piuttosto lungo. La mia soluzione per questo problema &egrave; stata
scrivere un programma che cercasse nel mezzo della partizione. Si chiama <tt/fsgrab/;
ne potete trovare il sorgente sul 
<url url="http://pobox.com/&tilde;aaronc/tech/fsgrab-1.2.tar.gz"
     name="mio sito web">
e presto arriver&agrave; su 
<url url="http://metalab.unc.edu/pub/Linux/utils/file/"
     name="Metalab">
(e sui suoi mirror). Se volete usare questo metodo, il resto di questo mini-Howto 
assume che abbiate <tt/fsgrab/.

Se nessuno dei file che state provando a recuperare &egrave; pi&ugrave; lungo di
12 blocchi (dove un blocco di solito &egrave; un kilobyte), allora non avrete
bisogno di <tt/fsgrab/.

Se dovete usare <tt/fsgrab/ ma non volete scaricarlo e compilarlo, 
&egrave; piuttosto semplice
tradurre una linea di comando di <tt/fsgrab/ in una di <tt/dd/. Se avete

<tscreen>fsgrab -c <em/count/ -s <em/skip/ <em/device/</tscreen>

allora il comando di <tt/dd/ corrispondente (ma tipicamente molto pi&ugrave;
lento) &egrave;

<tscreen>dd bs=1k if=<em/device/ count=<em/count/ skip=<em/skip/</tscreen>

Vi devo avvisare che, anche se <tt/fsgrab/ ha funzionato benissimo per me,
non posso prendermi alcuna responsabilit&agrave; per il suo uso. &Egrave; stata
una soluzione veramente veloce e improvvisata per fare funzionare le cose. Per altri
dettagli sulla mancanza di garanzia, vedere la sezione `Nessuna garanzia' nel file
<tt/COPYING/ incluso con il programma (la GNU General Public License).

<sect>Trovare gli inode cancellati<label id="sec-finding">

<p>Il prossimo passo &egrave; chiedere al filesystem quali inode sono stati 
liberati recentemente. &Egrave; un compito che si pu&ograve; portare a termine con
<tt/debugfs/; avviatelo con il nome del dispositivo in cui &egrave; immagazzinato il 
filesystem:

<tscreen><verb>
# debugfs /dev/hda5
</verb></tscreen>

Se volete modificare direttamente gli inode, aggiungete l'opzione <tt/-w/ per
abilitare la scrittura sul filesystem:

<tscreen><verb>
# debugfs -w /dev/hda5
</verb></tscreen>

Il comando di <tt/debugfs/ per trovare gli inode cancellati &egrave; <tt/lsdel/,
quindi, digitate il comando al prompt:

<tscreen><verb>
debugfs:  lsdel
</verb></tscreen>

Dopo molti lamenti e stridore dei meccanismi del disco, un lungo elenco viene mandato 
in pipe nel vostro pager preferito (il valore di <tt/&dollar;PAGER/). Ora vorrete 
salvarne una copia da qualche altra parte. Se avete <tt/less/, potete digitare <tt/-o/ seguito
dal nome di un file di output, altrimenti dovrete riuscire a mandare l'output da qualche
altra parte. Provate cos&igrave;:

<tscreen><verb>
debugfs:  quit
# echo lsdel | debugfs /dev/hda5 > lsdel.out
</verb></tscreen>

Ora, basandovi solo sull'ora di cancellazione, la dimensione, il tipo e i permessi
e l'owner espressi come numeri, dovrete riconoscere quali di questi inode cancellati
sono quelli che vi servono. Con un po' di fortuna, potrete riconoscerli perch&eacute; 
sono tutti quelli che avete cancellato circa cinque minuti fa. Altrimenti, cercate
con attenzione su tutta la lista.

Suggerisco che, se possibile, stampiate la lista degli inode che volete recuperare.
Vi render&agrave; la vita molto pi&ugrave; semplice.

<sect>Ottenere i dettagli degli inode<label id="sec-obtain">

<p><tt/debugfs/ ha un comando <tt/stat/ che stampa i dettagli su un inode. Date questo
comando per ciascun inode nella vostra lista. Ad esempio, se siete interessati all'inode
numero 148003, provate questo:

<tscreen><verb>
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
</verb></tscreen>

Se dovete recuperare moltissimi file, vorrete rendere questo passaggio automatico.
Assumendo che la lista degli inode da recuperare sia nel file <tt/lsdel.out/, provate
con questo:

<tscreen><verb>
# cut -c1-6 lsdel.out | grep "[0-9]" | tr -d " " > inode
</verb></tscreen>

Questo nuovo file, <tt/inode/, contiene il numero degli inode da recuperare, uno per
linea. Lo salviamo perch&eacute; molto probabilmente torner&agrave; comodo pi&ugrave;
tardi. Date semplicemente:

<tscreen><verb>
# sed 's/^.*$/stat <\0>/' inode | debugfs /dev/hda5 > stats
</verb></tscreen>

e <tt/stats/ conterr&agrave; l'output di tutti i comandi <tt/stat/.

<sect>Recuperare i blocchi di dati<label id="sec-recover">

<p>Questa parte pu&ograve; essere molto semplice o molto poco, a seconda
che il file che state cercando di recuperare sia pi&ugrave; lungo di 12
blocchi.

<sect1>File corti

<p>Se il file non era pi&ugrave; lungo di 12 blocchi, allora i numeri dei blocchi di 
tutti i suoi dati sono immagazzinati nell'inode: li potete leggere direttamente
dall'output di <tt/stat/ per l'inode. Inoltre, <tt/debugfs/ ha un comando che fa 
questo compito automaticamente. Per continuare con l'esempio di prima, ripetuto qui:

<tscreen><verb>
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
</verb></tscreen>

Questo file ha sei blocchi. Dato che questo corrisponde a meno del limite di 12,
usiamo <tt/debugfs/ per scrivere il file in una nuova posizione, come 
<tt>/mnt/recovered.000</tt>:

<tscreen><verb>
debugfs:  dump <148003> /mnt/recovered.000
</verb></tscreen>

Naturalmente, potete fare lo stesso con <tt/fsgrab/; qui sotto presento un esempio
del suo uso:

<tscreen><verb>
# fsgrab -c 2 -s 594810 /dev/hda5 > /mnt/recovered.000
# fsgrab -c 4 -s 594814 /dev/hda5 >> /mnt/recovered.000
</verb></tscreen>

Sia con <tt/debugfs/ che con <tt/fsgrab/, ci saranno dei caratteri inutili alla fine
di <tt>/mnt/recovered.000</tt>, ma non &egrave; molto importante. Se volete 
sbarazzarvene, il metodo pi&ugrave; semplice &egrave; prendere il campo <tt/Size/
dall'inode, e metterlo nell'opzione <tt/bs/ della linea di comando di <tt/dd/:

<tscreen><verb>
# dd count=1 if=/mnt/recovered.000 of=/mnt/resized.000 bs=6065
</verb></tscreen>

Naturalmente, &egrave; possibile che uno o pi&ugrave; dei blocchi che compongono
il vostro file siano stati sovrascritti. Se &egrave; cos&igrave;, siete sfortunati: 
quel blocco &egrave; perso per sempre (ma pensate se aveste smontato il filesystem prima!).

<sect1>File pi&ugrave; lunghi

<p>I problemi compaiono quando il file &egrave; pi&ugrave; lungo di 12 blocchi di dati.
Qui conviene sapere un po' come sono strutturati dei filesystem UNIX. I dati del file
sono immagazzinati in unit&agrave; chiamate `blocchi'. Questi blocchi possono essere
numerati sequenzialmente. Un file ha anche un `inode', che &egrave; il posto in cui 
vengono immagazzinate informazioni come il proprietario, i permessi ed il tipo. 
Come i blocchi, gli inode sono numerati sequenzialmente, anche se con una numerazione
separata. Una voce di una directory consiste nel nome del file e nel numero di un inode.

Ma con questo stato di cose &egrave; ancora impossibile per il kernel trovare 
i dati corrispondenti ad una voce di una directory, quindi nell'inode vengono
anche registrati i numeri dei blocchi di dati del file, cos&igrave;:

<itemize>
<item>I numeri di blocchi dei primi 12 blocchi vengono immagazzinati direttamente
nell'inode; questi vengono a volte chiamati <em/blocchi diretti/.

<item>L'inode contiene il numero di blocco di un <em/blocco indiretto/.
Un blocco indiretto contiene i numeri di blocco di altri 256 blocchi di dati.

<item>L'inode contiene il numero di blocco di un <em/blocco doppiamente indiretto/.
Un blocco doppiamente indiretto contiene i numeri di blocco di altri 256 blocchi 
doppiamente indiretti.

<item>L'inode contiene il numero di blocco di un <em/blocco triplamente indiretto/.
Un blocco triplamente indiretto contiene i numeri di blocco di altri 256 blocchi 
triplamente indiretti.
</itemize>

Leggetelo ancora: lo so che &egrave; complesso, ma &egrave; anche importante.

Ora, l'implementazione del kernel per tutte le versioni fino alla 2.0.36 
compresa
sfortunatamente azzera tutti i blocchi indiretti (e 
quelli doppiamente indiretti e cos&igrave; via) quando cancella un file;
quindi se il file in questione era pi&ugrave; lungo di 12 blocchi, non avete
alcuna garanzia di riuscire a trovare nemmeno i numeri di tutti i blocchi
componenti il file, pensate poi i loro contenuti.

L'unico metodo che sono riuscito a trovare finora &egrave; di assumere che
il file non era frammentato: se lo era, siete nei guai. Assumendo che il file
non fosse frammentato, ci sono diversi schemi per i blocchi dei dati, a seconda
di quanti blocchi dati il file usava:

<descrip>
<tag/da 0 a 12/I numeri di blocco sono registrati nell'inode, come sopra descritto.

<tag/da 13 a 268/Dopo i blocchi diretti, contatene uno per il blocco indiretto, e poi
ci sono 256 blocchi di dati.

<tag/da 269 a 65804/Come prima, ci sono 12 blocchi diretti, uno indiretto (inutile),
e 256 blocchi; questi sono seguiti da un blocco doppiamente indiretto (inutile),
e 256 ripetizioni di un blocco indiretto (inutile) e 256 blocchi di dati.

<tag/65805 o pi&ugrave;/Lo schema dei primi 65804 blocchi sono come nel precedente 
esempio. Poi segue un blocco triplamente indiretto (inutile) e 256 ripetizioni 
di una `sequenza doppiamente indiretta'. Ogni sequenza direttamente indiretta 
consiste di un blocco doppiamente indiretto (inutile), seguito da 256 ripetizioni di
un blocco indiretto (inutile) e 256 blocchi di dati.
</descrip>

Naturalmente, anche se questi numeri di blocchi di dati assunti sono corretti,
non c'&egrave; garanzia che i dati in essi contenuti siano intatti. Oltre a 
ci&ograve;, pi&ugrave; lungo era il file, minore &egrave; la possibilit&agrave; 
che sia stato scritto nel filesystem senza una frammentazione apprezzabile
(eccetto in circostanze speciali).

Da notare che ho sempre assunto che la dimensione dei blocchi sia di 
1024 byte, dato che &egrave; questo il valore standard. Se avete blocchi
pi&ugrave; grandi, alcune delle cifre riportate qui sopra sono errate. 
In particolare, dato che ciascun numero di blocco &egrave; lungo 4 byte, 
dimblocchi/4 &egrave; il numero di blocchi che pu&ograve; essere immagazzinato
in ciascun blocco indiretto. Quindi, ogni volta che il numero 256 appare nella
discussione qui sopra, sostituitelo con dimblocchi/4. Dovrete modificare
anche i limiti sul `numero di blocchi richiesto'.

Esaminiamo un esempio di recupero di un file lungo.

<tscreen><verb>
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
</verb></tscreen>

Sembra esserci una possibilit&agrave; ragionevole che questo file non sia 
frammentato: di sicuro, i primi 12 blocchi elencati nell'inode
(che sono tutti blocchi di dati) sono contigui; quindi possiamo cominciare a recuperare 
quelli:

<tscreen><verb>
# fsgrab -c 12 -s 8314 /dev/hda5 > /mnt/recovered.001
</verb></tscreen>

L'ultimo blocco elencato nell'inode &egrave; 8583. Notate che stiamo ancora bene 
per quanto riguarda la contiguit&agrave; del file: l'ultimo blocco di dati che 
abbiamo scritto era l'8582, che &egrave; 8327 + 255. Questo blocco 8583 &egrave; un 
blocco doppiamente indiretto, e quindi possiamo ignorarlo. &Egrave; seguito da 256 
ripetizioni di un blocco indiretto (che possiamo ignorare) seguito da 256 blocchi 
di dati; quindi, facendo un rapido conto, diamo i seguenti comandi. Notate che saltiamo
il blocco indiretto 8583, e il blocco indiretto 8584 immediatamente (speriamo) successivo,
e cominciamo a cercare i dati dal blocco 8585.

<tscreen><verb>
# 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
</verb></tscreen>

Facendo le somme, vediamo che finora abbiamo scritto 12 + (7 * 256)
blocchi, che fa 1804. I risultati di `stat' per l'inode ci avevano dato un conteggio
di 3616; sfortunatamente questi blocchi sono lunghi 512 byte (una conseguenza di UNIX),
quindi in realt&agrave; ci servono 3616/2 = 1808 blocchi di 1024 byte. Ci&ograve;
significa che ci servono ancora quattro blocchi. L'ultimo blocco scritto era il numero
10125. Come abbiamo fatto finora, saltiamo un blocco indiretto (il numero 10126), e poi
possiamo scrivere quegli ultimi quattro blocchi.

<tscreen><verb>
# fsgrab -c 4 -s 10127 /dev/hda5 >> /mnt/recovered.001
</verb></tscreen>

Ora, con un po' di fortuna avremo recuperato l'intero file.

<sect>Modificare gli inode direttamente<label id="sec-modify">

<p>Questo metodo &egrave;, superficialmente, molto pi&ugrave; semplice; comunque,
come gi&agrave; detto, non pu&ograve; gestire file pi&ugrave; lunghi di 12 blocchi.

Per ogni inode che volete recuperare, dovete impostare lo usage count a uno, e
il deletion time a zero: si fa con il comando <tt/mi/ (modify inode) di <tt/debugfs/.
Un esempio di output, modificando l'inode 148003 di cui sopra:

<tscreen><verb>
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]
</verb></tscreen>

Cio&egrave; imposto il deletion time a 0 e il link count a 1 e premete semplicemente invio
per ciascuno degli altri campi. &Egrave; garantito, &egrave; un po' noioso se avete 
molti file da recuperare, ma ci potete riuscire... altrimenti potete usare un 
`sistema operativo' grafico con un simpatico `Cestino'.


Tra l'altro: l'output di <tt>mi</tt> si riferisce ad un campo `Creation time'
nell'inode. &Egrave; una bugia! O comunque, trae in inganno. Il fatto &egrave; che
su un sistema UNIX non si pu&ograve; dire quando &egrave; stato creato un file.
Il membro <tt/st_ctime/ di una <tt/struct stat/ si riferisce al `tempo di modifica 
dell'inode', cio&egrave; il momento in cui sia stato modificato un dettaglio dell'inode.
Qui finisce la lezione di oggi.

Notate che le versioni di <tt/debugfs/ pi&ugrave; recenti di quella che sto usando 
probabilmente non includono alcuni dei campi che ho elencato sopra
(in particolare, <tt/Reserved1/ e (alcuni) campi di fragment).

Una volta modificati gli inode, potete uscire da <tt/debugfs/ e dire:

<tscreen><verb>
# e2fsck -f /dev/hda5
</verb></tscreen>

L'idea &egrave; che ciascuno dei file cancellati &egrave; stato recuperato,
ma nessuno di essi compare in un elenco di directory. Il programma <tt/e2fsck/
pu&ograve; accorgersene, ed aggiungere una voce di directory per ciascun file 
nella directory <tt>/lost+found</tt> del filesystem (quindi se la partizione 
&egrave; normalmente montata su <tt>/usr</tt>, i file ora saranno in 
<tt>/usr/lost+found</tt> quando la rimonterete). 
Tutto quello che rimane da fare &egrave; scoprire il nome
di ciascun file dai suoi countenuti, e rimetterlo al suo posto corretto nell'albero
delle directory.

Quando usate <tt/e2fsck/ avrete un output molto interessante, ed alcune
domande su quale danno riparare. Rispondete `s&igrave;' a tutto quello che si
riferisce alle `summary information' o agli inode che avete modificato.
Tutto il resto viene lasciato a voi, anche se di solito &egrave; una buona idea
rispondere affermativamente a tutte le domande. Quando <tt/e2fsck/ ha finito potete
rimontare il filesystem.

In realt&agrave; c'&egrave; un'alternativa a fare lasciare i file in <tt>/lost+found</tt>
ad <tt/e2fsck/: potete usare <tt/debugfs/ per creare un link all'inode nel filesystem. 
Usate il comando <tt/link/ di <tt/debugfs/ dopo aver modificato l'inode:

<tscreen><verb>
debugfs:  link <148003> pippo.txt
</verb></tscreen>

Questo crea un file <tt/pippo.txt/ in quella che <tt/debugfs/ crede sia la 
directory corrente: <tt/pippo.txt/ sar&agrave; il vostro file. Dovrete
ancora usare <tt/e2fsck/ per aggiustare le informazioni di indice e i conteggi
dei blocchi e cos&igrave; via.

<sect>Diventer&agrave; pi&ugrave; facile in futuro?<label id="sec-easier">

<p>S&igrave;. In effetti, credo che sia gi&agrave; cos&igrave;. Mentre sto
scrivendo, i kernel stabili (nella serie 2.0.x) azzerano i blocchi indiretti,
cosa che non accade a quelli di sviluppo 2.1.x, n&eacute; ai 2.2.x. 
Il kernel 2.2.1 &egrave; stato rilasciato da poco (siamo nel Febbraio 1999),
ed i rivenditori di Linux probabilmente inizieranno a produrre distribuzioni
di Linux che contengano i kernel 2.2.x tra un mese o due.
Una volta superata questa limitazione nel kernel di produzione, molte delle
mie obiezioni alla tecnica della modifica manuale degli inode spariranno;
allo stesso tempo sar&agrave; anche possibile
usare il comando <tt/dump/ nel <tt/debugfs/ sui file lunghi.

<sect>Ci sono strumenti per automatizzare questo processo?

<p>In realt&agrave; esistono. Sfortunatamente credo che soffrano dello stesso
problema della tecnica della modifica manuale degli inode: i blocchi indiretti non
possono essere recuperati. Comunque, data la probabilit&agrave; che questo non 
sar&agrave; a breve un problema, conviene dare un'occhiata a questi programmi 
gi&agrave; adesso.

Io ho scritto un programma che si chiama <tt/e2recover/, essenzialmente
un wrapper Perl su <tt/fsgrab/. Fa un ragionevole sforzo per gestire
i blocchi indiretti azzerati, e sembra funzionare sufficientemente bene
finch&eacute; il filesystem non &egrave; frammentato. Imposta anche 
correttamente i permessi (e quando possibile l'owner) dei file recuperati, 
e si assicura che essi abbiano la lunghezza corretta.

Originariamente ho scritto <tt/e2recover/ per il prossimo aggiornamento
globale di questo howto; sfortunatamente ci&ograve; significa che molta
della documentazione utile per <tt/e2recover/ uscir&agrave; con quel documento.
Potrebbe essere per&ograve; utile gi&agrave; da adesso, quindi &egrave; 
disponibile sul <url url="http://pobox.com/~aaronc/tech/e2-undel/" name="mio
sito web"> e presto su Metalab.

Scott D. Heavner &egrave; l'autore di <tt/lde/, il Linux Disk Editor. 
Pu&ograve; essere usato sia come editor binario di dischi, sia come 
l'equivalente di <tt/debugfs/ per i filesystem ext2 e minix, ed anche per
gli xia (anche se il supporto xia non &egrave; pi&ugrave; disponibile
nei kernel 2.1.x e 2.2.x). Ha alcune caratteristiche per aiutare nel 
recupero dei file dalla cancellazione, sia per cercare un file nell'elenco
dei blocchi sia per fare delle ricerche nel contenuto del disco. Ha
anche della buona documentazione sui concetti base dei filesystem, oltre
ad un documento su come usarlo per recuperare i file. La versione 2.4 di 
<tt/lde/ &egrave; disponibile su
<url url="http://metalab.unc.edu/pub/Linux/system/filesystems/lde-2.4.tar.gz"
name="Metalab">
e sui suoi mirror, o sul
<url url="http://www.geocities.com/CapeCanaveral/Lab/7731/lde.html"
     name="sito web dell'autore">.


Un'altra possibilit&agrave; &egrave; il GNU Midnight Commander,
<tt/mc/. Si tratta di uno strumento di gestione di file full-screen, basato per quanto ne
so su un certo programma MS-DOS comunemente noto come `NC'. <tt/mc/ supporta il
mouse sulla console di Linux e sugli xterm, e fornisce un filesystem virtuale
che permette trucchi come fare <tt/cd/ dentro un file tar. Tra i suoi filesystem virtuali ce n'&egrave;
uno per il recupero di file su ext2. Sembra molto comodo, anche se ammetto che non
l'ho mai usato personalmente -- preferisco i vecchi comandi di shell.

Per usare la sua caratteristica di recupero dei file, si deve configurare il 
programma con l'opzione <tt/--with-ext2undel/;
avrete anche bisogno delle librerie di sviluppo e dei file include
presenti nel 
pacchetto <tt/e2fsprog/. La versione fornita nella
<url url="http://www.debian.org/" name="Debian GNU/Linux"> &egrave; gi&agrave;
configurata cos&igrave;; la stessa cosa pu&ograve; essere per le altre 
distribuzioni. 
Una volta compilato il programma, potete
dire di fare <tt/cd undel:/dev/hda5/, ed avere un `elenco di directory' dei file cancellati. Come nella maggior parte degli strumenti di recupero dei file, 
non gestisce bene i blocchi indiretti azzerati, e tipicamente recupera solo
i primi 12k dei file lunghi. 

Trovate l'ultima versione sul
<url url="ftp://ftp.nuclecu.unam.mx/Midnight/devel/"
     name="sito fto di Midnight Commander">.

L'ultima versione non di sviluppo &egrave; probabilmente la 4.0; come con
il kernel stesso, le versioni di sviluppo <em/non/ sono raccomandate 
ai non sviluppatori. La lista degli oltre 70 siti da cui scaricarlo &egrave;
disponibile sul
<url url="http://mc.blackdown.org/mc4/"
     name="sito web di Midnight Commander 4">,
o provate il 
<url url="ftp://ftp.nuclecu.unam.mx/linux/local/mc-4.0.tar.gz"
     name="sito ftp ufficiale">
(che se la memoria non mi inganna &egrave; piuttosto lento).


<sect>Colophon

<p>Intendo produrre aggiornamenti regolari a questo documento finch&eacute; 
avr&ograve; tempo per farlo e cose interessanti da dire. Ci&ograve; significa
che sono avido di conoscere i commenti dei lettori. Posso essere pi&ugrave; chiaro?
Riuscite a pensare a qualcosa che possa rendere le cose pi&ugrave; facili? 
Esiste qualche nuovo strumento che lo fa in automatico? 

In ogni caso, se avete qualcosa da dire, su questo documento o su <tt/fsgrab/
o <tt/e2recover/, mandatemi due righe a 
<tt><htmlurl url="mailto:aaronc@pobox.com" name="aaronc@pobox.com"></tt>.

<sect>Crediti e ringraziamenti<label id="sec-credits">

<p><quote>`If I have seen farther than others, it is because I was standing on
the shoulders of giants.' (Isaac Newton)</quote>

Questo mini-Howto deriva originariamente da un articolo su 
<tt><htmlurl url="news:comp.os.linux.misc" name="comp.os.linux.misc"></tt>
di Robin Glover
<tt><htmlurl url="mailto:swrglovr@met.rdg.ac.uk"
             name="swrglovr@met.rdg.ac.uk"></tt>.
Vorrei ringraziare Robin per avermi gentilmente permesso di rielaborare le sue idee in
questo mini-Howto. Vorrei inoltre sfruttare questa opportunit&agrave; per 
ringraziare ancora tutti quelli che mi hanno scritto sull'Howto. Vale la 
pena di sforzarsi, se si ricevono commenti positivi.

Alcuni riferimenti bibliografici:

<itemize>
<item><bf/Frisch/, Ęleen (1995), <em/Essential System Administration/, seconda edizione,
O'Reilly and Associates, Inc., ISBN: 1-56592-127-5.

<item><bf/Garfinkel/, Simson, Daniel <bf/Weise/ and Steven <bf/Strassmann/
(1994), <em/The Unix-Haters Handbook/, IDG Books, ISBN: 1-56884-203-1. 
Gran parte di questo libro sono solo le lamentele adolescenziali di persone
che pensano che il <em/loro/ sistema operativo era molto meglio di Unix, e
molto del resto non si applica se avete uno spazio utente ben scritto come
quello GNU... ma c'&egrave; del buono, ad esempio vale la pena leggere
la discussione su come &egrave; facile cancellare i file sotto Unix.

<item><bf/Glover/, Robin (31 Jan 1996), <em>HOW-TO : undelete linux files
(ext2fs/debugfs)</em>,  Articolo di usenet su comp.os.linux.misc.

<item><bf/Peek/, Jerry, Tim <bf/O'Reilly/, Mike <bf/Loukides/ et al (1993),
<em/UNIX Power Tools/, O'Reilly and Associates, Inc./Random House, Inc., ISBN:
0-679-79073-X, seconda edizione 1998.
</itemize>

<sect>Legalese

<p>Tutti i marchi registrati sono propriet&agrave; dei rispettivi possessori.
In particolare:

<itemize>

<item><em/MS-DOS/ e <em/Windows/ sono marchi registrati della
<url url="http://www.microsoft.com/" name="Microsoft">.

<item><em/UNIX/ &egrave; un marchio registrato di 
<url url="http://www.opengroup.org/" name="the Open Group">.

<item><item><em/Linux/ &egrave; un marchio registrato di Linus Torvalds negli
USA ed in alcune altre nazioni.
</itemize>

Questo documento &egrave; Copyright © 1997, 1999 Aaron Crane
<tt><htmlurl url="mailto:aaronc@pobox.com"
             name="aaronc@pobox.com"></tt>.
Pu&ograve; essere liberamente distribuito nella sua interezza, inclusa tutta questa 
nota di copyright, ma non pu&ograve; essere modificato senza permesso dell'autore o del
coordinatore degli HOWTO del Linux Documentation Project. Viene data una dispensa per la copia di piccole
porzioni per recensioni o come citazione; in queste circostanze possono essere
riprodotte delle sezioni in presenza di una citazione appropriata, anche senza questa 
nota di copyright.

L'autore si augura ma non richiede che chi intenda vendere copie di questo documento,
sia su un mezzo leggibile su computer o da persone, informi lui o il coordinatore
dei Linux HOWTO delle sue intenzioni.

Il coordinatore dei Linux HOWTO &egrave; al momento Tim Bynum
<tt><htmlurl url="mailto:linux-howto@sunsite.unc.edu"
             name="linux-howto@sunsite.unc.edu"></tt>.

Traduzione di Eugenia Franzoni, <tt>eugenia@pluto.linux.it</tt>.
</article>

