Actually, I would like to support this motion... Thinking over the possible=
behaviours of -P is to sit in a room saying "to delete or not to delete...=
" If you think it over from a higher perspective, "The UNIX Way" (TM) is t=
o have individual commands for specific tasks and to extract tasks from com=
mands that have gotten too complex... and I think this is the case of rm...=
a "shred" command should be added that has the following behaviour:=0A=0A=
if the file is not writable, return with error.=0Aif the file has multiple =
links, and option -f was not specified, return with error.=0Aoverwrite the =
file.=0Aoptionally, unlink the file.=0A=0AAdditionally, -P should either be=
rm'ed from rm, or added as a backwards compatibility hack that calls "shre=
d" and returns with error every time the latter does.=0A=0AThese are my 1.9=
9 cents.=0A=0A=0A- Daniel=0A=0A=0A----- Original Message ----=0AFrom: Tim C=
lewlow =0ATo: Bakul Shah ; Doug B=
arton =0ACc: delphij@FreeBSD.org; perryh@pluto.rain.com;=
freebsd-hackers@freebsd.org=0ASent: Monday, October 30, 2006 12:20:33 PM=
=0ASubject: Re: [patch] rm can have undesired side-effects=0A=0A=0A--- Baku=
l Shah wrote:=0A=0A> Sorry if I tuned in late:-)=0A> =
=0A> I vote for taking *out* -P. It is an ill-designed=0A> feature.=0A> Or=
if you keep it, also add it to mv, cp -f & ln -f=0A> since=0A> these comma=
nds can also unlink a file and once=0A> unlinked in=0A> this matter you can=
't scrub it. And also fix up the=0A> behavior=0A> for -P when multiple lin=
ks. And since mv can use=0A> rename(2),=0A> you will have to also dirty up=
the kernel interface=0A> somehow.=0A> Not to mention even editing such a s=
ensitive file=0A> can leave=0A> stuff all over the disk that a bad guy can =
get at. =0A> If you=0A> are truely paranoid (as opposed to paranoid only=0A=
> when on=0A> meds) you know how bad that is!=0A> =0A> If you are that conc=

ious about scrubbing why not add=0A> scrubbing as a mount option (suggested=
option: -o=0A> paranoid)=0A> then at least it will be handled consistently=
..=0A> =0A> What's the world come to when even the paranoid are=0A> such=0A>=
amateurs.=0A> =0A> -- bakul=0A> =0A=0ABased on all the potential situation=
s where a -P=0Aoption may possibly be implemented, is it worthwhile=0Aconsi=
dering creating a command that just scrubs a=0Afile, and does nothing else.=
This would seem to fit=0Athe Unix paradigm of single command to do a singl=
e=0Athing, and may be preferable to attempting to embed=0Athis function in =
every command that may "possibly"=0Aremove a file.=0A=0AJust my 2c=0A=0ATim=
=0A=0A=0A=0A______________________________________ _________________________=
_____________________=0ALow, Low, Low Rates! Check out Yahoo! Messenger's c=
heap PC-to-Phone call rates =0A(http://voice.yahoo.com)=0A=0A______________=
_________________________________=0Afreebsd-hackers@freebsd.org mailing lis=
t=0Ahttp://lists.freebsd.org/mailman/listinfo/freebsd-hackers=0ATo unsubscr=
ibe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"=0A=0A
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis...reebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"