Date: Tue, 31 Oct 2006 08:16:40 -0800 (PST) From: Daniel Valencia <fetrovsky@yahoo.com> To: freebsd-hackers@freebsd.org Subject: Re: [patch] rm can have undesired side-effects Message-ID: <20061031161640.71807.qmail@web53907.mail.yahoo.com>
next in thread | raw e-mail | index | archive | help
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 <tim1timau@yahoo.com>=0ATo: Bakul Shah <bakul@bitblocks.com>; Doug B= arton <dougb@FreeBSD.org>=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 <bakul@bitblocks.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061031161640.71807.qmail>