Newsgroup: it.comp.hardware.storage
Titolo: Impossibile cancellare file anche dopo formattazione

Buongiorno a tutti,
vi scrivo per una cosa che ha dell'incredibile, ci ho a che fare da
settimane e non mi capacito della cosa. Andiamo con ordine. Alcune
settimane fa durante una pulizia generale del PC (disinstallazione di
programmi vari, deframmentazione, pulitura del registro etc.) ho
verificato la presenza di file cancellati ma recuperabili. Ne trovo
uno, un file zippato che contiene le mie email personali. Considerando
che il trasloco dei dati su questo PC l'ho fatto più di un anno e
mezzo fa, il file dovrebbe risalire a quel periodo. La cosa già di per
sé mi sembra strana, provo a recuperarlo e vedo che in effetti è
recuperabile: ho il mio file zippato con i contenuti perfettamente
leggibili. Provo ad effettuare una sovrascrittura sicura tramite la
stessa utility che me l'ha rilevato, ovvero Piriform Recuva. Il
programma mi dà il seguente messaggio d'errore: Impossibile
sovrascrivere tipi di file speciali. La partizione in questione è una
partizione logica di un centinaio di GB, con filesystem NTFS, OS
Windows XP Professional, distinta dalla partizione di sistema. La
seconda prova è stata quella di lanciare un programma per
l'eliminazione sicura dei file (eraser versione 6.0.8) con l'opzione
di cancellare lo spazio vuoto. Dopo un bel po' di tempo (operazione
lanciata nel fine settimana) riprovo con recuva: il file è sempre
presente. Il fine settimana seguente, pensando che in qualche modo
windows potesse bloccare la scrittura di alcune parti del disco, metto
su chiavetta una BackTrack, monto la partizione e lancio il comando
sfill. Nisba. Decido di risolvere il problema una volta per tutte.
Copio tutto il contenuto della partizione su un HD esterno. Lancio la
BackTrack, rimuovo ogni file, lancio sfill -l (che a questo punto mi
sovrascrive tutta la partizione), formatto con mkntfs (senza nessuna
opzione per la formattazione veloce, tant'è vero che per la
formattzione è stata necessaria quasi un'ora) e ricopio i file nella
partizione. Bhe, quando ho verificato che il file infame è ancora
presente e recuperabile non potevo crederci. Ora non so più cosa fare.
Qualcuno ha dei suggerimenti?

Scriveva lipschitz martedì, 21/12/10:

Curiosa la cosa in effetti... come ultima spiaggia potresti usare DBAN 
oppure ZAP per "piallare" completamente l'HD.
Se manco quelli funzionano allora la situazione è tale da dover 
chiamare un esorcista :)

 sovrascrive tutta la partizione)
Se la partizione è vuota, usa la via semplice (e più sicura: le
molteplici passate di sfill sono completamente inutili da un lato
e gravemente insufficienti dall'altro: se ci metti di mezzo un
filesystem, non puoi essere sicuro che sia sovrascritto *tutto*
quel che deve esserlo).
Sia per ipotesi /dev/sdz9 la famosa partizione.
# dd if=/dev/zero of=/dev/sdz9 bs=8M
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
_____________________________________________________________________
Non sprecare i cicli idle della tua CPU. Usali per qualcosa di utile.
http://orbit.psi.edu/
 
http://www.worldcommunitygrid.org/index.jsp
 
http://boinc.berkeley.edu/projects.php

 # dd if=/dev/zero of=/dev/sdz9 bs=8M
mi permetto di modificare in:
dd if=/dev/urandom of=/dev/sd9 bs=8M
S.

 dd if=/dev/urandom of=/dev/sd9 bs=8M
Così però è *molto* più lento.
Inoltre sovrascrivere con tutti zeri o con dati casuali è
*praticamente* indifferente, a meno che poi non si voglia
crittare la partizione (nel qual caso urandom servirebbe a
non far distinguere i dati crittati dallo spazio libero).
Dimenticate le favole di Gutmann[*], un settore sovrascritto è un 
settore sovrascritto, con che cosa non conta *praticamente*. :)
E, se per ipotesi assurda contasse, allora urandom non basterebbe,
ci vorrebbe almeno random: il che non sarebbe assolutamente
fattibile, perché se urandom dà anche parecchi MB/s, random nella
migliore delle ipotesi su un normale pc darà qualche centinaio di
B/s. :)
[*] 
http://www.nber.org/sys-admin/overwritten-data-gutmann.html
