From owner-freebsd-current@FreeBSD.ORG Thu Sep 27 11:37:25 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 D462316A477 for ; Thu, 27 Sep 2007 11:37:25 +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 9B47013C48E for ; Thu, 27 Sep 2007 11:37:25 +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 48F9C244C48; Thu, 27 Sep 2007 20:37:24 +0900 (JST) Message-ID: <46FB95F4.2000706@freebsd.org> Date: Thu, 27 Sep 2007 20:37:24 +0900 From: Daichi GOTO User-Agent: Thunderbird 2.0.0.6 (X11/20070803) MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG, Masanori OZAWA References: <200709251800.l8PI0lof013108@lurza.secnetix.de> In-Reply-To: <200709251800.l8PI0lof013108@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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 11:37:25 -0000 Oliver Fromme 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. > > I think it could cause confusion for some users or admins. > > It could also be dangerous. I remember an emergency case > when /home was an NFS mount that was dead, i.e. every > process that tried to access something in /home just hung > forever in state "D" (disk wait). During the emergency > actions on the serial console I also needed to use the > rm(1) command ... Now if it tried to read ~/.rm, it would > have drawn me mouch deeper into trouble than I already > were. :-) True, the -f option would have prevented it, > _if_ I remembered before to use it. We have realized that issue, but do not understand thats cause still now. Do you know the reason? > A common precaution against accidental rm is to establish > a snapshot rotation system. For example, create hourly > snapshots (with a cron job) and delete them automatically > after a while. So if you accidentally remove something, > you can copy it back from the latest snapshot. NetApp > Filers have such a feature built-in. You can also easily > set it up yourself with ZFS, or even with UFS snapshots, > although the latter are a bit heavyweight, IMHO. Yes. At the moment ZFS looks a best way of snapshot feature. I have heard that snapshot of UFS2 is slow under very mass files and heavy load situation. > And finally, there is chflags(1). If you know in advance > that certain files or directories must not be removed, > then "chflags schg" or "chflags uchg" them. That's the > same effect as creating a ~/.rm file with your patch. Yes. It is one of the ways :) > Another advantage of chflags(1) is that it also protects > against other kinds of damage. For example when using > shell redirection ("echo > some/important/file"), cp, dd > or other commands. In those cases chflags also offers > protection (and a snapshot would offer recovery), while > your patch only protects against rm and nothing else. > > Just my 2 cents. > > Best regards > Oliver -- Daichi GOTO, http://people.freebsd.org/~daichi