From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 24 05:18:06 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9070106564A for ; Mon, 24 Mar 2008 05:18:06 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (student.mired.org [66.92.153.77]) by mx1.freebsd.org (Postfix) with ESMTP id 3F0778FC1A for ; Mon, 24 Mar 2008 05:18:05 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 67919 invoked by uid 1001); 24 Mar 2008 01:17:11 -0400 Received: from bhuda.mired.org (192.168.195.1) by bhuda.mired.org (tmda-ofmipd) with ESMTP; Mon, 24 Mar 2008 01:17:09 -0400 Date: Mon, 24 Mar 2008 01:17:08 -0400 To: Message-ID: <20080324011708.107ec3cb@bhuda.mired.org> Organization: Meyer Consulting X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.8; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Mike Meyer Subject: Problem with find -prune... 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: Mon, 24 Mar 2008 05:18:06 -0000 find -prune seems to not quite do what it says. At least, when delete is used. Here's an example tree (on 7.0-RELEASE, amd64 build): bhuda# ls -Rl /tmp/x total 2 drwx------ 2 root wheel 512 Mar 24 01:01 y /tmp/x/y: total 2 -rw-r--r-- 1 root wheel 1111 Mar 24 01:01 motd /tmp/x contains a subdirectory closed to everyone but root, which has a file in it. No problem. Point find at it as a user: bhuda% find /tmp/x -print /tmp/x /tmp/x/y find: /tmp/x/y: Permission denied As expected, it complains. Now let's use prune to trim the search - at the root of the tree: bhuda% find /tmp/x -prune /tmp/x Hmm, it prints the root of the tree. That might be a bug; might not. But we can fix it with a little tweak: bhuda% find /tmp/x -prune -o -print bhuda% Making the print conditional on not pruning, and we always prune. Ok, now let's look at what looks to me like a bug: bhuda% find /tmp/x -prune -o -delete find: /tmp/x/y: Permission denied Why on earth (or off it) is find trying to look at /tmp/x? Am I correct in assuming that this is a bug? Thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.