From owner-freebsd-current@FreeBSD.ORG Thu Sep 27 12:10:19 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3AED16A468 for ; Thu, 27 Sep 2007 12:10:19 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.232.58]) by mx1.freebsd.org (Postfix) with ESMTP id 864FB13C4D1 for ; Thu, 27 Sep 2007 12:10:19 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.232.62]) by natial.ongs.co.jp (Postfix) with ESMTP id 71376244C3A for ; Thu, 27 Sep 2007 21:10:18 +0900 (JST) Message-ID: <46FB9DAA.1080104@freebsd.org> Date: Thu, 27 Sep 2007 21:10:18 +0900 From: Daichi GOTO User-Agent: Thunderbird 2.0.0.6 (X11/20070803) MIME-Version: 1.0 To: FreeBSD Current References: <46F905FD.9060208@freebsd.org> <20070925194008.3c2d7113@epia-2.farid-hajji.net> <20070926114705.GA12643@holyman.cobbled.net> In-Reply-To: <20070926114705.GA12643@holyman.cobbled.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: The safety expansion for FreeBSD rm(1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2007 12:10:19 -0000 Oh yeah--it's an interesting point, and we are going to think about it :) ttw+bsd@cobbled.net wrote: > Daichi GOTO 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. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Daichi GOTO, http://people.freebsd.org/~daichi