L'uomo è più intelligente del proprio sistema operativo. Qualche volta, almeno.
Alcune situazioni appaiono più gravi di quanto in effetti siano. In questa parte procederemo all'acquisizione di una immagine del supporto ed a una prima diagnosi.
Inseriamo il pen drive nella presa USB, aspettiamo qualche secondo, poi col comando dmesg controlliamo che il drive sia correttamente rilevato:
# dmesg
usb 1-4: new high speed USB device using ehci_hcd and address 2
usb 1-4: configuration #1 chosen from 1 choice
Initializing USB Mass Storage driver...
scsi2 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: device scan complete
scsi 2:0:0:0: Direct-Access USB2.0 Flash Disk 4.00 PQ: 0 ANSI: 2
sd 2:0:0:0: [sdc] 517759 2048-byte hardware sectors (1060 MB)
sd 2:0:0:0: [sdc] Write Protect is off
sd 2:0:0:0: [sdc] Mode Sense: 00 00 00 00
sd 2:0:0:0: [sdc] Assuming drive cache: write through
sd 2:0:0:0: [sdc] 517759 2048-byte hardware sectors (1060 MB)
sd 2:0:0:0: [sdc] Write Protect is off
sd 2:0:0:0: [sdc] Mode Sense: 00 00 00 00
sd 2:0:0:0: [sdc] Assuming drive cache: write through
sdc: sdc1
sd 2:0:0:0: [sdc] Attached SCSI removable disk
sd 2:0:0:0: Attached scsi generic sg3 type 0
Nell'esempio mostrato il pen drive USB è da 1 Gbyte, contiene una partizione singola e viene
messo a disposizione dal kernel come dispositivo /dev/sdc, mentre la
partizione è disponibile come /dev/sdc1.
Un primo segnale che c'è poco da fare è quando la dimensione riportata dal kernel è differente da quella reale. Ho avuto per le mani un pen drive da 2 Gbyte che il kernel riportava essere da 8 Mbyte, ed una scheda flash di tipo Secure Digital (SD) da 512 Mbyte che il kernel riportava essere da 32 Mbyte.
Le dimensioni riportate dal kernel sono quelle dichiarate dal dispositivo stesso, tramite una funzione propria dei dispositivi di storage. Se il drive dichiara di essere grande 8 Mbyte, quando invece è più grande, non rimane che cestinarlo. Potrebbe essere disponibile da parte del produttore una qualche utility specifica che serve a recuperarne le funzioni, ma quasi mai succede, e spesso è anche difficile capire chi sia il produttore reale.
Il fatto che sia riportata una partizione fa supporre che la tabella delle partizioni sia integra, ma facciamo un controllo mirato:
# fdisk -l /dev/sdc
Nota: la dimensione del settore è 2048 (non 512)
Disco /dev/sdc: 1060 MB, 1060370432 byte
255 heads, 63 sectors/track, 32 cylinders
Units = cilindri of 16065 * 2048 = 32901120 bytes
Disk identifier: 0x1653a4c6
Dispositivo Boot Start End Blocks Id System
/dev/sdc1 1 32 1028034 6 FAT16
Nell'esempio il comando riesce a leggere correttamente la tabella delle partizioni, e restituisce valori congruenti, indice che la tabella delle partizioni è al suo posto.
Alcuni pen drive sono formattati come un super-floppy, ossia senza tabella di partizioni.
In questo caso non esisterà il device /dev/sdc1, ed il comando
appena visto restituirebbe messaggi ben diversi:
Questa non sembra una tabella delle partizioni.
Probabilmente è stato scelto il dispositivo sbagliato.
Dispositivo Boot Start End Blocks Id System
/dev/sdc1 ? 105945 226473 3872573504 d Sconosciuto
La partizione 1 ha diversi elementi iniziali fisici/logici (non Linux?):
phys=(255, 105, 46) logico=(105944, 128, 27)
La partizione 1 ha diversi elementi finali fisici/logici:
phys=(370, 10, 5) logico=(226472, 198, 48)
...
... tanti altri messaggi di errore
...
La partizione 4 non termina al limite del cilindro.
Le voci nella tabella delle partizioni non sono nello stesso ordine del disco
Questo non significa che il drive sia perso. Può darsi che siamo nella situazione del super floppy. Lo potremo accertare nei passi successivi.
Siamo pronti per l'acquisizione. Occorre stabilire la posizione dei file che andremo a
creare, ovviamente dove abbiamo spazio. Supponiamo di avere un disco completamente a
disposizione, già montato. Ci spostiamo nella directory in cui è montato, che supporremo
essere /media/discousb. Attenzione, questo è il disco
dove andiamo a salvare il contenuto recuperato, non il disco da
recuperare. Il comando per iniziare il recupero dell'immagine è:
# dd if=/dev/sdc1 of=/media/discousb/pendrive.img bs=2048 conv=noerror,syncche andiamo a spiegare:
if=/dev/sdc1: è il device che rappresenta la partizione da
recuperare. Se siamo nel caso C va cambiato in if=/dev/sdc, per
acquisire l'intero disco. Lo stesso se siamo nel caso A o B, e non esiste il device
/dev/sdc1, indice che il supporto è trattato come un
super floppy.
of=/media/discousb/pendrive.img: è il file su cui verrà copiato
l'intero disco. Questa operazione ci permetterà di lavorare sull'immagine o su una
copia di essa senza toccare il disco originale, con il vantaggio di poter tentare
diverse alternative senza alterare definitivamente il supporto originale.
bs=2048: è la dimensione in byte del settore fisico del supporto, come
dichiarato dal supporto stesso nell'output del comando fdisk dato
poco sopra. Attenzione che deve sempre essere specificato, e che nei supporti
flash spesso non è 512 byte, ma 1024 o 2048. La
dimensione del settore fisico è sempre riportata da fdisk anche se
la tabella delle partizioni è corrotta o non esiste proprio.
conv=noerror,sync: queste due direttive di acquisizione indicano che
l'acquisizione deve continuare anche in caso di errori di lettura del supporto
(noerror), e che quando un settore fisico non può essere letto dal
supporto originale deve essere considerato come vuoto, ossia scritto nel file immagine
come tutti i byte a zero. Questo serve per mantenere intatta la struttura e
l'indirizzamento del supporto: se i settori errati venissero semplicemente ignorati le
strutture dati del filesystem da recuperare punterebbero nel posto sbagliato, dato che
l'immagine sarebbe composta di meno settori, omessi praticamente a caso.
Con questo comando viene acquisita l'intera partizione (o supporto nel caso
/dev/sdc) in una unica passata. Ecco un esempio con un mio pen drive da
1 gigabyte:
# dd if=/dev/sdc1 of=/media/discousb/pendrive.img bs=2048 conv=noerror,sync
514017+0 records in
514017+0 records out
1052706816 bytes (1,1 GB) copied, 109,364 s, 9,6 MB/s
Al termine possiamo scollegare il supporto da recuperare, dato che lavoreremo sull'immagine, o meglio su una copia di essa.
Se abbiamo poco spazio disponibile ed il disco da recuperare è molto grande dobbiamo per forza di cose acquisire l'immagine un pezzo alla volta e lavorarla man mano, ma in un certo senso siamo nei guai: non potendo lavorare sull'immagine fedele del contenuto del disco non potremo utilizzare tutti gli strumenti, ma solo foremost. Se siamo nel caso C, questo non fa molta differenza in realtà, perché probabilmente le strutture dati del filesystem sono perse in partenza e forse l'unica possibilità rimasta è proprio foremost.
Per acquisire l'immagine un pezzo alla volta, possiamo cambiare il comando aggiungendo in
coda l'opzione count=n, dove n è il numero di blocchi di
dimensione bs da leggere prima di fermarsi. Per il primo blocco il comando
è:
# dd if=/dev/sdc1 of=/media/discousb/pendrive.img bs=2048 conv=noerror,sync count=1000000
se vogliamo leggere un blocco di 2.048.000.000 byte (un milione di blocchi da 2048 byte).
Per leggere il blocco successivo il comando deve tenere conto del fatto che abbiamo già
letto i primi 1.000.000 di blocchi, quindi introduciamo l'opzione skip=n,
che significa "salta i primi n blocchi in input", in questo modo:
# dd if=/dev/sdc1 of=/media/discousb/pendrive.img bs=2048 conv=noerror,sync count=1000000 skip=1000000che prende un altro milione di blocchi a partire dall'ultimo letto. Il terzo blocco sarà letto col comando:
# dd if=/dev/sdc1 of=/media/discousb/pendrive.img bs=2048 conv=noerror,sync count=1000000 skip=2000000e via così, fino alla fine del supporto.
Per ragioni che vedremo fra poco, possiamo anche far sovrapporre le sezioni dell'immagine.
Servirà quando useremo foremost, e l'entità della sovrapposizione è
determinata empiricamente dalla tipologia di file da recuperare: se il disco contiene le
nostre foto, possiamo supporre che la dimensione media sia intorno al megabyte (o più,
dipende dal formato e dalla risoluzione), se invece contiene filmati in formato Xvid o
simili, è lecito supporre che la dimensione media dei file sia di 500-700 megabyte. La
sovrapposizione dovrebbe essere dello stesso ordine di grandezza, operando a scelta sul
conteggio dei blocchi da leggere o sul numero dei blocchi da saltare, aggiungendo al
parametro count o sottraendo al parametro skip tanti
blocchi fino alla dimensione voluta della sovrapposizione.
Al termine di questa fase avremo uno o più file rappresentanti l'immagine del disco da recuperare. Se abbiamo un solo file, ossia abbiamo acquisito l'intero disco in un solo passo, possiamo fare dei controlli di livello più alto, altrimenti dobbiamo affidarci direttamente al recupero tramite foremost (Sezione 4, «Estremi rimedi»).
Prima di passare alle operazioni di analisi e recupero, facciamo una copia del file immagine: lavoreremo su quella e non su quella acquisita, che rimarrà intatta ed a disposizione per altre prove.
Gran parte dei pen drive, dei lettori MP3 e delle memorie
flash sono dotati di questo tipo di filesystem (o di una
delle sue varianti). Questo perché è semplice da gestire e adatto a dispositivi non troppo
sofisticati come appunto fotocamere digitali e lettori MP3. Supponendo di aver fatto una
copia dell'intera immagine del pen drive nel file copia.img, facciamo
in modo che sia disponibile come un normale device, su cui possiamo fare tutte le operazioni
normalmente disponibili su un disco. Il comando da usare è:
# losetup /dev/loop0 copia.img
che non restituisce nessun messaggio in caso di esecuzione corretta. Il device creato sarà
/dev/loop0, e possiamo verificarlo con il comando:
# losetup -a
/dev/loop0: [0811]:43264319 (/media/discousb/copia.img)
a conferma che è tutto in ordine. Con questa operazione abbiamo creato un cosiddetto loop device, ossia un dispositivo virtuale che usa un file invece di un supporto fisico.
Sempre continuando l'esempio con il mio pen drive, che usa FAT come filesystem, se siamo nel caso A o nel caso B possiamo usare l'utility dosfsck (disponibile anche con i nomi fsck.vfat e fsck.msdos) nel pacchetto dosfstools. Questa utility effettua un controllo molto simile al comando chkdsk di Windows, solo che Linux ne permette l'uso sull'immagine appena acquisita, indirizzandolo sul loop device appena creato:
# dosfsck -v /dev/loop0
dosfsck 2.11 (12 Mar 2005)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "MSDOS5.0"
Media byte 0xf8 (hard disk)
2048 bytes per logical sector
16384 bytes per cluster
2 reserved sectors
First FAT starts at byte 4096 (sector 2)
2 FATs, 16 bit entries
129024 bytes per FAT (= 63 sectors)
Root directory starts at byte 262144 (sector 128)
512 root directory entries
Data area starts at byte 278528 (sector 136)
64235 data clusters (1052426240 bytes)
63 sectors/track, 255 heads
63 hidden sectors
514017 sectors total
Checking for unused clusters.
/dev/loop0: 321 files, 52348/64235 clusters
Questo è l'output atteso quando non sono presenti problemi. Ma nel caso A l'output è simile a questo:
# dosfsck -v /dev/loop0
...
...
Checking for unused clusters.
Reclaimed 2851 unused clusters (46710784 bytes).
Leaving file system unchanged.
/dev/loop0: 316 files, 49497/64235 clusters
oppure, molto peggio, a questo:
#dosfsck -v /dev/loop0 ... ... FATs differ but appear to be intact. Use which FAT ? 1) Use first FAT 2) Use second FAT?_
L'utility aspetta una decisione da noi. Notare che nessuno dei comandi usati finora modifica effettivamente i dati, perché non abbiamo ancora incluso una opzione che abilita la scrittura reale delle modifiche. Possiamo dare due volte lo stesso comando scegliendo la prima volta la prima FAT e successivamente la seconda e basarsi sul numero di errori per scegliere quella più in buono stato. Nell'esempio, dove ho deliberatamente "sfasciato" la prima FAT. Se scelgo appunto la prima il risultato è:
?1/foto-nipoti/Immagine 003.jpg Contains a free cluster (3074). Assuming EOF. /foto-nipoti/Immagine 003.jpg File size is 1626051 bytes, cluster chain length is 245760 bytes. Truncating file to 245760 bytes. Checking for unused clusters. Reclaimed 2870 unused clusters (47022080 bytes). Leaving file system unchanged. /dev/loop0: 316 files, 49412/64235 clusters
mentre se scelgo la seconda FAT il risultato è:
?2Checking for unused clusters. Reclaimed 2851 unused clusters (46710784 bytes). Leaving file system unchanged. /dev/loop0: 316 files, 49497/64235 clusters
Probabilmente in questo caso scegliere la seconda FAT porta ad un miglior risultato. Spesso la realtà è molto più complicata, e una possibile strategia è di riparare il supporto applicando tutte e due le varianti, agendo ogni volta su una copia dell'immagine, recuperare tutti i file e confrontare poi il risultato. Ovviamente l'operazione è lunga e faticosa, ma stiamo parlando di recuperare dati importanti, quindi partiamo dal presupposto che ne valga la pena.
E' umanamente impensabile trattare tutti possibili i casi, ed occorre una buona conoscenza di come è fatto il filesystem su cui andiamo ad agire. Per brevità supponiamo di aver trovato la strada migliore per riparare il filesystem. Ora il comando da usare sarà:
#dosfsck -r -f /dev/loop0 dosfsck 2.11, 12 Mar 2005, FAT32, LFN FATs differ but appear to be intact. Use which FAT ? 1) Use first FAT 2) Use second FAT?2Reclaimed 2851 unused clusters (46710784 bytes) in 4 chains.Perform changes ? (y/n)y/dev/loop0: 320 files, 52348/64235 clusters
dove le opzioni usate stanno a significare: -r per “effettua
realmente il recupero”, cioè scrivi sul supporto, -f indica di
convertire le catene di cluster in file invece di cancellarle come avviene nel comportamento
predefinito. Infatti il numero di file è aumentato di 4 unità.
Possiamo ora montare l'immagine del pen drive come un normale disco e recuperarne il contenuto:
# mount -t vfat /dev/loop0 /media/pendrive
dove /media/pendrive è una directory creata apposta da
noi per montare l'immagine riparata del pen drive. A questo punto con i normali comandi di
manipolazione dei file possiamo esplorarne il contenuto e recuperare quello che ci serve.
Abbiamo usato un pen drive poco "disastrato": un errore abbastanza banale sulla FAT e 4 file che non apparivano nella directory principale ed occupavano spazio. Nella realtà i danni possono essere più estesi, o essere danneggiate entrambe le copie della FAT, per cui ben poco si recupera con questo sistema. Ecco un esempio con un lettore musicale da 1 gigabyte:
#dosfsck -v /dev/loop0 dosfsck 2.11 (12 Mar 2005) dosfsck 2.11, 12 Mar 2005, FAT32, LFN Checking we can access the last sector of the filesystem There are differences between boot sector and its backup. Differences: (offset:original/backup) 0:eb/66, 1:58/0f, 2:90/b6, 3:4d/46, 4:53/10, 5:44/66, 6:4f/8b, 7:53/4e , 8:35/24, 9:2e/66, 10:30/f7, 11:00/e1, 12:02/66, 13:08/03, 14:20/46 , 15:00/1c, 16:02/66, 17:00/0f, 18:00/b7, 19:00/56, 20:00/0e, 21:f8/66 , 22:00/03, 23:00/c2, 24:3f/66, 25:00/89, 26:ff/46, 27:00/fc, 28:30/66 ... ... parecchie altre righe ... , 486:0d/00, 487:0a/00, 505:ac/00, 506:bf/00, 507:cc/00 1) Copy original to backup 2) Copy backup to original 3) No action?3è ininfluente Boot sector contents: System ID "MSDOS5.0" Media byte 0xf8 (hard disk) 512 bytes per logical sector 4096 bytes per cluster 32 reserved sectors First FAT starts at byte 16384 (sector 32) 2 FATs, 32 bit entries 1018880 bytes per FAT (= 1990 sectors) Root directory start at cluster 2 (arbitrary size) Data area starts at byte 2054144 (sector 4012) 254660 data clusters (1043087360 bytes) 63 sectors/track, 255 heads 48 hidden sectors 2041296 sectors total Both FATs appear to be corrupt. Giving up.
Qui la situazione è decisamente peggiore. Già il boot sector appare affetto da errori, anche
se l'originale, visualizzato col comando hexdump sembra contenere dati
validi, fra cui il System ID, riportato come MSDOS5.0.
Entrambe le copie della FAT appaiono corrotte, ed a questo punto niente altro si può fare
con questo metodo.
Prima di tentare altro, vediamo di riassumere. La procedura fin qui presentata permette di acquisire sotto forma di singolo file l'immagine del supporto (o meglio di una sua partizione) e di lavorarci sopra come se fosse un normale disco. Questo consente di tentare più strade differenti senza sottoporre il supporto ad ulteriori stress e senza trovarci nella spiacevole situazione in cui tentando prima una strada sbagliata rendiamo il danno irreparabile, quando invece era recuperabile, almeno in parte.
In caso di supporti prossimi al guasto finale, che presentino già i sintomi producendo errori di lettura e di accesso, questa procedura permette di salvare il salvabile, sottoponendo il supporto ad un ultimo stress, la lettura per intero in modo sequenziale, molto meno stressante di un tentativo di recupero effettuato direttamente.
Il mio primo pen drive era da 128 megabyte, ed avevo pensato bene di togliere il filesystem FAT che vi era sopra e sostituirlo con il più adatto ext3, visto che lo scopo era di usare il drive con Linux e basta. Ebbene, l'errore è proprio questo: il filesystem ext3 utilizza strutture dati estremamente complesse, rispetto a FAT, con la conseguenza che quanto detto sulla durata nel tempo delle memorie flash diventa ancora più critico. Tanto è vero che tale pen drive è durato molto poco, approssimativamente 3 mesi. Per capirci, in ext3 ogni singolo accesso ad un file, anche in sola lettura, viene registrato nel filesystem stesso, quindi anche le letture si trasformano in scritture. In più la presenza di un sistema di journaling moltiplica ogni singola operazione di scrittura.
Probabilmente anche la qualità del pen drive non era eccelsa, ma l'uso del filesystem sbagliato ne ha pesantemente abbreviato la vita. Quindi, a parte situazioni particolari, lasciate il pen drive col filesystem che ha in origine.
La situazione attuale è che il pen drive risulta compreso nel caso B: il filesystem contiene errori tali da impedirne l'uso regolare (non viene eseguito il mount) e risulta non scrivibile: neanche una formattazione o una scrittura diretta ottiene risultati.
Anche in questo caso la procedura è perfettamente applicabile, a parte alcuni dettagli. L'acquisizione dell'immagine del pen drive è assolutamente identica, usando il comando dd come visto sopra.
Per il recupero del contenuto si opera sempre attraverso un loop
device creato a partire dal file dell'immagine. Supponendo che l'immagine
della partizione del pen drive si chiami pen128m.img il comando sarà:
# losetup /dev/loop0 pen128m.imgPer controllare e riparare il filesystem il programma da usare sarà fsck.ext3, che ha l'equivalente funzione di dosfsck, per il filesystem ext3:
# fsck.ext3 -pv /dev/loop0
chiave: Superblock has an invalid ext3 journal (inode 8).
CLEARED.
*** ext3 journal has been deleted - filesystem is now ext2 only ***
chiave was not cleanly unmounted, check forced.
chiave: Journal inode is not in use, but contains data. CLEARED.
chiave: Inode 25 is in use, but has dtime set. FIXED.
chiave: Inode 25 has imagic flag set.
chiave: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
Abbiamo provato a lasciar fare il lavoro al programma (-p impone a
fsck.ext3 di andare in automatico), ma questo richiede il nostro
intervento, per cui riproviamo:
#fsck.ext3 -v /dev/loop0 e2fsck 1.40.2 (12-Jul-2007) chiave contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Inode 25 has imagic flag set.Clear<y>?yesInode 26 is in use, but has dtime set.Fix<y>?yes... ... parecchie altre domande ...
Chiave era il nome che avevo dato al pen drive.
Se vediamo che le domande sono veramente tante (molte delle quali sono incomprensibili a chi
non conosce ext2/ext3 come le proprie tasche), possiamo tentare una differente strategia,
scegliendo di far compiere il lavoro in modo automatico, aggiungendo l'opzione
-y (risponditi sempre “yes”):
# fsck.ext3 -yv /dev/loop0
...
... tanti messaggi
...
Free inodes count wrong (32855, counted=31901).
Fix? yes fsck.ext3 si autorisponde “yes”
chiave: ***** FILE SYSTEM WAS MODIFIED *****
99 inodes used (0.31%)
0 non-contiguous inodes (0.0%)
# of inodes with ind/dind/tind blocks: 959/955/954
4760 blocks used (3.73%)
0 bad blocks
0 large files
34 regular files
4 directories
15 character device files
15 block device files
15 fifos
4294967294 links
1 symbolic link (1 fast symbolic link)
5 sockets
--------
37 files
In questo caso l'elaborazione è molto rapida, anche se non abbiamo idea di cosa sia stato recuperato e cosa no. Per questo montiamo il file immagine del pen drive riparato e andiamo a vedere:
#mount /dev/loop0 /media/pendrive#ls /media/pendrive lost+found#ls -l /media/pendrive/lost+found totale 2 drwxrwxr-- 3 mario mario 1024 4 ago 2005 #10001 c--x-w-r-t 1 1716867345 3721182105 221, 153 11 set 2015 #1201 prwx-wxr-x 1 4283800016 3403281 0 31 mag 2004 #1204 c--xr--rwT 1 3430355198 2290623095 17, 119 20 mar 1988 #1206 ... ... ... c--xr--rwT 1 3430351102 2290623095 17, 119 20 mar 1988 #310 s-wsrwsrwx 1 3758087543 1414992382 0 7 ott 1915 #321 b-wxrwsrwt 1 1719118591 1946104831 204, 255 21 set 2015 #329 drwx------ 2 mario mario 1024 14 set 2005 #4001 prwx-wxr-x 1 4283816024 3403345 0 19 lug 2004 #436 c--sr---wT 1 3430355198 2290623095 17, 119 20 mar 1988 #438 s-ws-wsrwx 1 3758087543 1347883518 0 7 ott 1915 #449 b-wxrwsrwt 1 1719118591 1946104831 204, 255 21 set 2015 #457 ... ... ... c--xr---wT 1 3430355198 2290623095 17, 119 20 mar 1988 #950 b-wxrwsrwt 1 1718987519 1946104831 196, 255 21 set 2015 #969
I file recuperati che non hanno più un nome vengono inseriti nella directory lost+found, con il nome sostituito dal numero del blocco (in
realtà sarebbe l'inode) da cui parte. Come possiamo vedere
gran parte dei file hanno permessi, dimensione, proprietario e date inconsistenti, a parte
due directory, #4001 e #10001. Possiamo considerare perso il resto. Andiamo a vedere
nelle due directory:
#ls -l /media/pendrive/lost+found/#10001/ totale 669 -rwxr-xr-x 1 mario mario 1610 29 giu 2005 disktemp -rw-rw-r-- 1 mario mario 248106 25 giu 2005 ds1621.pdf -rw-rw-r-- 1 mario mario 310158 16 giu 2005 DS1631-DS1731.pdf -rw-r--r-- 1 mario mario 15475 28 giu 2005 LCDd.conf ... ... ... -rw-r--r-- 1 mario mario 410 2 ago 2005 smssendd.conf -rwxr-xr-x 1 mario mario 1032 3 ago 2005 snmpsms -rw-rw-r-- 1 mario mario 5624 25 giu 2005 therm-sens-i2c.sch#ls -l /media/pendrive/lost+found/#4001 totale 34 -rw------- 1 mario mario 348 22 feb 2005 certificato_revoca.asc -rw------- 1 mario mario 8075 31 ago 2004 gpg.conf -rw------- 1 mario mario 10275 7 lug 2005 pubring.gpg -rw------- 1 mario mario 8196 7 lug 2005 pubring.gpg~ -rw------- 1 mario mario 600 21 set 2005 random_seed -rw------- 1 mario mario 1666 4 giu 2005 secring.gpg -rw------- 1 mario mario 1600 17 ago 2005 trustdb.gpg
A quanto pare il contenuto di queste due directory è intatto. Andando a copiare i file su un supporto integro e aprendoli uno per uno il contenuto è valido e leggibile.
Se avessimo dei dubbi sul totale recuperato, possiamo sempre riprendere l'immagine del pen drive e sottoporlo alla procedura spiegata più avanti (Sezione 4, «Estremi rimedi»).
Per chiudere questo argomento, più il filesystem è sofisticato, più diventa penoso il recupero, anche per via della mancanza di conoscenza delle intime strutture e del funzionamento del singolo tipo di filesystem. Torniamo a ripetere che niente può sostituire un regolare backup dei nostri dati.
Se il supporto è con filesystem NTFS siamo nei guai. Nel senso che di questo filesystem si conosce poco e anche quel poco è in gran parte ricavato tramite reverse engineering, visto che le specifiche delle strutture dati di questo filesystem non sono disponibili. Un recente progetto, denominato ntfs-3g, sta tentando di creare delle utility affidabili, il minimo necessario per accedere in maniera sicura a dischi con questo filesystem, senza fare danni. Non si dispone al momento di un equivalente di dosfsck (il comando ntfsfix corregge solo alcuni errori di minore entità e forza poi un controllo con chkdsk quando si riparte con Windows).
In effetti, nessun pen drive fra quelli che mi sono capitati era con questo filesystem, e solo due dischi fra quelli che ho avuto per le mani usavano NTFS, ma avevano ben altri problemi (uno dei due era già morente ed ha esalato l'ultimo respiro mentre lo leggevo con dd, l'altro era stato sottoposto ad un programmino automagico che aveva fatto scomparire una decina di directory piene di foto). Per questo motivo non lo tratteremo. Se siamo nel caso B o nel caso C, il filesystem potrebbe essere comunque irrecuperabile, e quindi fa poca differenza in che filesystem sia il supporto.