Re: summer of code - scrub feature

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Sun, Mar 22, 2009 at 04:44:28PM -0400, Thor Lancelot Simon wrote:
> On Sun, Mar 22, 2009 at 06:00:51PM +0200, Stathis Kamperis wrote:
> > Greetings everyone,
> > 
> > I hereby express my interest in the implementation of the "scrub data
> > blocks before deletion" project, as part of the summer of code.
> > I am going to investigate the topic a bit more and write my
> > application in the next couple of days.
> 
> What does this feature get us that rm -P doesn't already?

Nothing. Well, nothing that a decent implementation of rm -P wouldn't
cure. And no, I don't believe the study recently that said that a
single overwrite left no traces of previous data, but I'm kinda funny
that way.

Yes, and there's the ability to have f?truncate(2) catered for by
overwriting with random gibberish.

Oh, and not having to remember to specify -P to rm for any file that
you want to make sure is overwritten, because it's too late once those
data blocks make it back onto the freelist. I suppose you could take the
hit and alias rm -P, and wait while directory trees take ages to delete.
We're all too busy anyway, these days, and could do with a break.

Then there's the fact that rm isn't the only way to issue an unlink(2)
or truncate(2) or ftruncate(2) system call - I mean, we very rarely use
rm -rf, or tar --unlink, or 'cat > file', 'cc -o file' or any other
means.

However, the other part of this project is concerned (potentially)
with dealing with random data in the kernel, so that might conceivably
have some benefits for the project as a whole.

Still you're right - makes me think I wonder why I proposed this
project now.

Regards,
Alistair