From owner-freebsd-current@FreeBSD.ORG Wed Sep 26 11:47:18 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 947E016A417 for ; Wed, 26 Sep 2007 11:47:18 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: from mail1.slb.deg.dub.stisp.net (mail1.slb.deg.dub.stisp.net [84.203.253.98]) by mx1.freebsd.org (Postfix) with SMTP id 09AAE13C43E for ; Wed, 26 Sep 2007 11:47:17 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: (qmail 20338 invoked from network); 26 Sep 2007 11:47:15 -0000 Received: from unknown (HELO holyman.cobbled.net) (84.203.180.117) by mail1.slb.deg.dub.stisp.net with SMTP; 26 Sep 2007 11:47:15 -0000 Received: by holyman.cobbled.net (Postfix, from userid 16385) id 24C89171B7; Wed, 26 Sep 2007 11:47:06 +0000 (UTC) Date: Wed, 26 Sep 2007 11:47:06 +0000 From: ttw+bsd@cobbled.net To: FreeBSD Current Message-ID: <20070926114705.GA12643@holyman.cobbled.net> Mail-Followup-To: FreeBSD Current References: <46F905FD.9060208@freebsd.org> <20070925194008.3c2d7113@epia-2.farid-hajji.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070925194008.3c2d7113@epia-2.farid-hajji.net> 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: Wed, 26 Sep 2007 11:47:18 -0000 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.