svn commit: r214596 - head/bin/rm

Ken Smith kensmith at buffalo.edu
Tue Nov 2 13:58:33 UTC 2010


On Tue, 2010-11-02 at 01:40 +0000, Alexander Best wrote:
> how about a compromise then? let's leave the -P switch in rm, but make it a no
> op! in addition to that add a new rm(1) entry explaining what the -P switch did
> and why exactly it was turned into a no op. let's be really eloborate on this
> issue and tell the user exactly every tiny detail that lead to the conclusion
> that currently the -P switch serves no purpose and thus it was turned into a no
> op. also a statement should be added to rm(1) that makes clear that the -P flag
> *will* come back to rm, once the low level work has been finished in order to
> decide (from userland) whether a specific disk supports overwriting blocks or
> not.
> 
> thoughts? 

This doesn't quite solve the issue I'm most concerned with.

As a "best practices" type thing people are told to be careful to erase
sensitive data.  People right now may be using "rm -P" to do that,
thinking they followed the best practices.  And how many of you re-read
the manual page for every command you use when a new version of the OS
comes out?  The tweaks to the manual page would prevent new people
from being fooled into thinking they're following best practices but
would do nothing to let people who found -P a while ago know they
aren't actually following best practices after all.

Making -P a no-op actually makes the above issue worse.  As Ceri said,
if anything it should fail.  But I'm not sure what the difference is
between -P failing any time you use it versus just removing -P until
the support for it is in place.  From the discussions so far it seems
like the world has changed to the point support for it may not be
possible.  

-- 
                                                Ken Smith
- From there to here, from here to      |       kensmith at buffalo.edu
  there, funny things are everywhere.   |
                      - Theodor Geisel  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20101102/13355e01/attachment.pgp


More information about the svn-src-head mailing list