Un file riscritto su NTFS utilizza gli stessi blocchi?

In generale , l'allocazione dei blocchi è l'operazione più costosa nei file system, quindi i filesystem proveranno a evitarlo, in particolare riutilizzando i blocchi quando possibile. Ciò significherebbe quanto segue:

• Quando si sovrascrive un file esistente, vengono riutilizzati gli stessi blocchi. I nuovi blocchi vengono assegnati quando i nuovi dati del file superano quelli dei file sovrascritti.

• Quando si tronca un file esistente, tutti i blocchi vengono rilasciati, quindi potenzialmente riutilizzabili per altre operazioni sui file. In tal caso, il nuovo file può allocare nuovi blocchi. Non vi è alcuna garanzia che il nuovo contenuto del file possa riallocare gli stessi blocchi, e, in particolare, i vecchi blocchi potrebbero essere stati riallocati ad altri file nel frattempo.

Tuttavia , dipende molto dagli interni del filesystem. Log filesystems strutturati eseguono tutte le scritture in modo sequenziale, su tutta la partizione, quindi è praticamente garantito, con tale filesystem, che il nuovo file non sovrascriva i blocchi dal vecchio file. File system di journaling possono copiare il contenuto del file in una struttura aggiuntiva (il "journal") oltre alla memoria permanente effettiva (a seconda se il journaling si estende al contenuto del file o solo ai metadati). Alcuni filesystem usano anche un "albero delle fasi" che può essere visto come un filesystem log-strutturato, con un albero invece di una lista; per questi, sovrascrivi possono o non possono accadere.

Un punto importante da considerare è che le strategie di allocazione dei blocchi non dipendono solo dal filesystem , ma anche dall'implementazione . Non c'è alcuna garanzia che Windows XP e Windows 7, ad esempio, si comportino allo stesso modo sullo stesso filesystem NTFS. Una versione del sistema operativo potrebbe trovare utile mantenere i vecchi blocchi per "accelerare la (ri) allocazione" mentre un'altra potrebbe utilizzare un'altra strategia. Questa è tutta l'euristica, messa a punto e risintonizzata. Quindi, non si può davvero rispondere alla tua domanda su "NTFS"; si dovrebbe parlare di "NTFS come implementato in OS foobar, versione 42.17, build 3891".

Inoltre , tutti questi blocchi sono ciò che vede l'OS; in realtà l'archiviazione fisica può essere diversa e spostare / copiare i dati. Questo è tipico degli algoritmi di livellamento dell'usura in SSD. In generale, la sovrascrittura / distruzione dei file su SSD non è affidabile (per ulteriori dettagli e indicazioni, consultare questa risposta ). Ma alcuni movimenti di dati possono verificarsi anche con dischi magnetici (in particolare quando viene rilevato un settore di fiocchi, la rimappatura viene eseguita al volo e il vecchio settore rimane intatto, per sempre).

Ciò significa che la distruzione dei file non funziona bene in quanto non può garantire che i dati vengano distrutti. Dovresti utilizzare la distruzione dei file solo come misura di emergenza quando altri metodi hanno fallito o sono stati erroneamente applicati. I modi corretti per distruggere definitivamente un file sono:

• Distruzione all'ingrosso del disco completo, ad es. dissolvendolo in acido.
• Crittografia : quando i dati vengono crittografati, distruggere la chiave è sufficiente per rendere irrecuperabili i dati. Anche se questo non risolve completamente il problema (devi ancora distruggere un elemento dati), lo rende molto più semplice (una chiave è piccola: è molto più facile distruggere 128 bit che distruggere 128 gigabyte ).

Cancellazione sicura , se implementato correttamente dal disco, funziona con trucco di crittografia.

Innanzitutto se l'unità è un SSD, no, perché oltre a tutto ciò che il sistema operativo sta facendo l'unità eseguirà il livellamento dell'usura, ciò significa che i dati verranno probabilmente scritti in una posizione diversa, anche se il sistema operativo sta scrivendo allo stesso blocchi.

In Windows, il descrittore di file include il nome del file, diversamente dalla maggior parte dei sistemi Linux che separano l'allocazione dei dati fisici da 9inone) dalla voce della directory (nome file). Quindi, quando inizi a riscrivere un file esistente, il sistema operativo scollegherà tutti i blocchi successivi dal primo, quindi il primo blocco rimane lo stesso, ma i blocchi successivi saranno riallocati a, d potrebbero essere allocati in modo diverso.

Sono disponibili strumenti che garantiscono la cancellazione sicura dei file, eseguono scritture distruttive sul file senza troncarlo e quindi rinominano il nome file per sovrascrivere la voce della directory.

Non puoi presumere che verranno utilizzati gli stessi blocchi. E come detto in altre risposte, con SSD e livellamento dell'usura, è fuori dal tuo controllo. Per un documento sensibile, proporrei un contenitore crittografato come TrueCrypt . Non dimenticare di utilizzare anche un file di scambio crittografato.

Questo comportamento è una caratteristica del software di elaborazione dei documenti che stai utilizzando di sicuro? È passato un po 'di tempo da quando ho consultato lo standard OOXML , se prendi il documento è abbastanza ... sano. Suppongo che tu stia utilizzando Microsoft Office, perdonami se ho fatto un salto troppo grande. Accoppiato con il fatto che il formato Zip che OOXML utilizza come contenitore rende le strutture disponibili nelle specifiche per lo streaming di porzioni del file dal contenitore, non riesco a pensare a un motivo per cui un documento creato in questo modo sarebbe un dato immutabile. struttura.

Se non è Office e l'applicazione funziona in questo modo, non sono sicuro che non verrà ottimizzata nel compilatore o nel kernel, a meno che l'ingegnere del software non sia esplicitamente in grado di disabilitare questa funzionalità.

Ma se volessi fare un controllo, puoi sempre usare fsutil per cercare ID file, un concetto simile sarebbe Posix INodes o VNodes, che se hai installato cygwin potresti ottenere la loro rappresentazione con ls -i .

Devo rispolverare gli interni delle varie architetture SSD, ma mi chiedo se questa domanda deriva da TRIM e come forse (almeno ad un certo punto) potreste non aver avuto la certezza che sovrascrivere un file con un la funzione casuale avrebbe effettivamente sovrascritto il file, invece di applicare un algoritmo di livellamento dell'usura per uniformare gli IOP sull'unità.

Spero che qualcuno possa far luce su questo, ma forse se non solo per la ginnastica mentale, potresti concentrarti sul problema sbagliato. Se avete bisogno di alcune garanzie ragionevoli dei vostri dati a riposo e questo documento è abbastanza sensibile da essere preoccupato per la perdita; forse il documento o l'unità dovrebbero essere crittografati.