From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 7 23:22:20 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B15DD16A420 for ; Tue, 7 Mar 2006 23:22:20 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2DC843D8D for ; Tue, 7 Mar 2006 23:22:03 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k27NLujE092446; Wed, 8 Mar 2006 02:21:56 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k27NLpP7092437; Wed, 8 Mar 2006 02:21:51 +0300 (MSK) (envelope-from yar) Date: Wed, 8 Mar 2006 02:21:51 +0300 From: Yar Tikhiy To: Jilles Tjoelker Message-ID: <20060307232151.GA91873@comp.chem.msu.su> References: <20060306174058.GA32164@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060306174058.GA32164@stack.nl> User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org Subject: Re: find(1) -d vs -prune; /etc/periodic/daily/100.clean-disks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2006 23:22:20 -0000 On Mon, Mar 06, 2006 at 06:40:58PM +0100, Jilles Tjoelker wrote: > find(1)'s -prune primary does not work if depth-first traversal (-d, > -depth, also implied by -delete) is in effect. The reason is that it is > (obviously) not possible to prune a directory when visiting it after all > entries in it. > > This causes /etc/periodic/daily/100.clean-disks (if enabled) to recurse > through all read-only and NFS filesystems as well. > > More concrete examples: > > find -d / \( '!' -fstype local -o -fstype rdonly \) -a -prune -o \( -name '*.core' -o -name '.nfs[A-z][0-9a-f][0-9a-f][0-9a-f][0-9a-f]4.4' \) -atime +1 -print >/dev/null 2>&1 > > find /someserver.mnt \( '!' -fstype local -o -fstype rdonly \) -a -prune -print >/dev/null 2>&1 > (/someserver.mnt assumed to be not a mount point here) > > Possible solutions/workarounds: > 1. do still call -prune and some primaries without side effects > in pre-order even if -d is in effect, even though this does not > fit at all in find(1)'s design. > 2. document the bug and run a find -x over all local r/w filesystems > in 100.clean-disks (-x and -d work together properly). > > What would be the best way to go on? The property of -prune with respect to -d is already documented on the find(1) manpage. As for 100.clean-disks, I fail to see why -prune is needed there. One can mount a file system read-write at a directory of a read-only file system. Some bullet-proof installations have their / mounted read-only. Perhaps the invocation of find(1) in 100.clean-disks should be as follows: find / -fstype local ! -fstype rdonly \( $args \) ... Does it make sense? -- Yar