Protection from the dreaded "rm -fr /"

[Roman Neuhauser]

# keramida at freebsd.org / 2004-10-03 02:02:26 +0300:
> On 2004-10-02 17:22, Garance A Drosihn <drosih at rpi.edu> wrote:
> > At 8:57 PM +0300 10/2/04, Giorgos Keramidas wrote:
> > >On 2004-10-02 21:23, Lee Harr <missive at hotmail.com> wrote:
> > >> How about:
> > >> chflags sunlnk /
> > >> ?
> > >
> > >Setting sunlink on / will only protect the / directory, not its
> > >descendants, so you don't gain much.
> >
> > We could add a new flag "srunlnk", or maybe even "srm-r".  The "rm"
> > command will always have to stat() the file it is given (just to
> > see if it is a directory), so it could check to see if this flag
> > is turned on.  If it is turned on, then 'rm' could refuse to honor
> > any '-rf' request on that directory. [...]
> 
> Hmmm.  This sounds much better indeed :-)

    have rm -r[f] behave just like
        find $@ -flags +sunlnk -prune -o -delete
    (I hope this is correct; if not: if the file has sunlnk among its
    chflags, skip it and its descendants)

    this is something I would, if not like, at least tolerate.
    specialcasing / stinks. it reminds me of all the RHEL machines I
    deal with at work that have alias rm rm -i, and I can only thank my
    luck this hasn't costed me an arm;
        ls | while read f; do rm -i $f; done
    is very dangerous, at least in bash.
    
    I have once deleted parts of my ~ with rm -fr *, but rm -fr / never
    happened to me, prolly because of my strong dependence on the shell
    completion.

    (I hope I'm not too drunk.)

-- 
If you cc me or remove the list(s) completely I'll most likely ignore
your message.    see http://www.eyrie.org./~eagle/faqs/questions.html