securely overwrite files with Python

[Bob Ippolito]

On Mar 5, 2004, at 5:54 PM, Skip Montanaro wrote:

>
>>> First: It is not possible. Let me cite some sentences from shred(1):
>>>
>>> CAUTION: Note that shred relies on a very important assumption: that
>>> the filesystem overwrites data in place.  This is the traditional way
>>> to do things, but many modern filesystem designs do not satisfy this
>>> assumption.
>
>     Bob> Somewhat OT, Mac OS X 10.3 is one of the operating systems 
> where
>     Bob> this assumption is false.  Files smaller than a certain size 
> get
>     Bob> automatically moved around on the disk when it makes sense to 
> do so
>     Bob> in order to reduce fragmentation.
>
> I'm not sure I understand how that can work.  Suppose I have multiple 
> (hard)
> links to a small file named "small".  If the OS moves it around to 
> reduce
> fragmentation (implying it will have a different inode next time it's
> opened) how does it efficiently track down and change all inode 
> references
> to it?  In theory it could keep a cache mapping inode numbers back to 
> the
> directories which reference them, but that could consume a fairly large
> chunk of memory to maintain.

I can't speak to what it does exactly, I'm no HFS+ or xnu expert, but I 
know it only applies to files under 20mb on journaled HFS+ file 
systems... I believe that HFS+ has a level of indirection between the 
file's "inode" (HFS+ probably calls it something else) and the set of 
blocks it is represented with on disk, so I don't believe that moving 
the blocks around really has anything to do with hard links or creating 
a new inode.

You can look for yourself if you're particularly interested.. it's part 
of the APSL licensed Darwin 7.x kernel (xnu):

( should be mountable by WebDAV )
http://www.opensource.apple.com/darwinsource/10.3.2/xnu-517.3.7/bsd/hfs/

files of interest would be:
hfs_hotfiles.c
hfs_readwrite.c
hfs_vnops.c

In particular, you would be interested in the hfs_relocate function in 
hfs_readwrite.c.

-bob