I don't think writing random information 7 times is going to be enough. I think that's enough to prevent an analog read head from seeing 3 layers back, but the track-alignment issues can leave information laying around longer.

There are standards published by the government that uses specific patterns, not random numbers. Gibson uses patterns designed with knowledge of how the run-length encoding works in his tester product--similar knowledge might be useful here too, to make sure the =physical= bits are all written.

I would think the first pass would "wipe", not just "delete" the sensitive files.

So, here is an idea. Implement a wiper that takes a file name, opens it for read/write access, and overwrites it n times with the required patterns or random data (making sure it's really flushed, etc.).

Then, queue the list of files to process. Put the "sensitive" files first, but eventually list all files.

Slack space can be accomidated by making a slack file that fills up the rest of the space, before starting.

That way, one program does it all, and it can be reasonably portable and not need lower-level disk access.