Secure delete with python
pink at odahoda.de
Tue Sep 7 00:16:52 CEST 2004
Ville Vainio wrote:
>>>>>>"Benjamin" == Benjamin Niemann <b.niemann at betternet.de> writes:
> >> fp = open(path, "wb")
> >> for i in range(os.path.getsize(path)):
> >> fp.write("*")
> >> fp.close()
> >> os.unlink(path)
> Benjamin> and there is no guarantee that this actually overwrites
> Benjamin> the old file. The filesystem may choose to write the new
> Benjamin> content at another location of the disk, leaving the
> Benjamin> original data untouched.
> Seriously? What OSen are known for doing this? I'd had thought that if
> the file size is unchanged, the data is always written over the old
I don't know, if there actually is a filesystem that does this, but
there is no rule (that comes to mind now at least) that forbids it. E.g.
I could imagine some kind of transactional FS that doesn't change the
original file until to finish the transaction (=close the file) to avoid
file corruption, if a program crashes while writing...
Modern filesystem do lots of things most people (including me) can't
imaging. ReiserFS e.g. packs several small files into one block. If such
a file grows (perhaps) the data is moved to a block of its own - and the
old data stays (unreferenced) on disk although you didn't conciously
made a copy of the file...
But I'm just thinking aloud - don't know if anything of this is true.
But I except to task of a "secure delete" to be pretty difficult.
> Also, when overwriting a file, it's better to do it several times,
> with alternating bit patterns and "syncing" the disk after each
> pass. Of course even that is not going to guarantee anything because
> it may just go to the hardware cache in the disk unit, but it's
> reasonable if you are overwriting lots of data at once.
> Performing these steps, you'll at least get a good false sense of
> security ;-).
More information about the Python-list