On Tue, Sep 25, 2007 at 07:40:08PM +0200, cpghost wrote: > On Tue, 25 Sep 2007 21:58:37 +0900 > Daichi GOTO <daichi_at_freebsd.org> wrote: > > > Today is not unionfs. Introduction for safety expansion of rm(1). > > I know that some unix folks have a experience that you remove some > > files or directories accidentally. Yes, me too. LoL > > > > Have you any dreams that rm(1) autonomously judges target should > > be remove or not? To complexify system base command is objectionable > > behavior but adding some little and simple mechanism to prevent a > > issue is acceptable I suppose. > > > > We have created safety expansion for rm(1). If you have any interests, > > please try follow patch. > > > > http://people.freebsd.org/~daichi/safety-rm/ > > > > Thanks :) > > Interesting idea, but isn't that a violation of POLA? Imagine an > unsuspecting sysadmin trying to rm something, and forgetting > or not knowing about ~/.rm? All they have to do is specify -f and ~/.rm is ignored so I don't think it's that big a deal. It does raise the potential of werid side effects in scripts, but since you have to deploy ~/.rm files for anything to happen, I don't see it as that big a deal. It might be useful to have the ability to turn off ~/.rm support via an environmental variable. > Isn't it better to protect important system directories with > something like: > # chflags sunlink /path/to/dir > and unprotect them with > # chflags nosunlink /path/to/dir > to avoid mistakes? The above change means you have to apply the hammer of chflags to do anything. The patch lets you specify certain directories where you're prompted instead. I see that as much more useful. -- Brooks
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:18 UTC