Date: Wed, 26 Sep 2007 11:47:06 +0000 From: ttw+bsd@cobbled.net To: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: The safety expansion for FreeBSD rm(1) Message-ID: <20070926114705.GA12643@holyman.cobbled.net> In-Reply-To: <20070925194008.3c2d7113@epia-2.farid-hajji.net> References: <46F905FD.9060208@freebsd.org> <20070925194008.3c2d7113@epia-2.farid-hajji.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Daichi GOTO <daichi@freebsd.org> wrote: [ ... ] > 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. this is a nice little feature but from an administrative point of view i don't think it will be used (i'm infallable, as are most admins ... at least within their own heads) and there are other more comprehensive (i.e. not just the rm binary) tools for critical paths (as others have pointed out). from a user perspective it would be nice to have '/etc/rm.conf' or something so the admin can prevent user foot shooting, however, how many user deletes will actually be performed by 'rm'. basically, it's very clever, non-intrusive feature but i just can't see any value from it. perhaps if, instead of overlapping the current flags function, you used this feature to allow the user to be prompted when deleting a 'uunlink' file, or so that a user may set places where 'rm' will effectively ignore the 'uunlink' flag. still not sure how much value but it may encourage the use of 'uunlink' so that more paths are protected (i.e. if more binaries are flags aware we don't need to constantly change flags to perform functions). one obstacle i can think of is that many files may be stored on filesystems incompatible with flags.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070926114705.GA12643>