Date: Tue, 02 Nov 2010 09:42:30 -0400 From: Ken Smith <kensmith@buffalo.edu> To: Alexander Best <arundel@freebsd.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Pawel Jakub Dawidek <pjd@FreeBSD.org>, Ulrich Spoerlein <uqs@FreeBSD.org> Subject: Re: svn commit: r214596 - head/bin/rm Message-ID: <1288705350.7246.24.camel@bauer.cse.buffalo.edu> In-Reply-To: <20101102014059.GA91353@freebsd.org> References: <201010310921.o9V9LSo4075408@svn.freebsd.org> <20101031160603.GD2160@garage.freebsd.pl> <20101031191119.GM46314@acme.spoerlein.net> <1288620951.3596.32.camel@bauer.cse.buffalo.edu> <20101102014059.GA91353@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-U70p7GzrMpUxTsTTu+x7
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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 swit=
ch 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 conclu=
sion
> that currently the -P switch serves no purpose and thus it was turned int=
o 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 orde=
r to
> decide (from userland) whether a specific disk supports overwriting block=
s or
> not.
>=20
> thoughts?=20
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. =20
--=20
Ken Smith
- From there to here, from here to | kensmith@buffalo.edu
there, funny things are everywhere. |
- Theodor Geisel |
--=-U70p7GzrMpUxTsTTu+x7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
iEYEABECAAYFAkzQFTkACgkQ/G14VSmup/YyfgCghXC/2nQvpe2bEZgEzSciN19f
828An3Mss8LjasqmHuNph0+79QswjhVK
=MrIi
-----END PGP SIGNATURE-----
--=-U70p7GzrMpUxTsTTu+x7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1288705350.7246.24.camel>