Problem with find -prune...

[Mike Meyer]

On Thu, 3 Apr 2008 17:59:20 +0200 (CEST) Oliver Fromme <olli at lurza.secnetix.de> wrote:

> Mike Meyer <> wrote:
>  > 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):
> It behaves exactly as documented.  I'll try to explain.

I think you did an excellent job. Thank you.

>  > 
>  > 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?
> 
> The -delete primary implicitly assumes depth-first
> traversal (i.e. the -d option), because that's the
> only way you can delete a whole directory tree.
> 
> However, when depth-first traversal is in effect,
> the -prune primary doesn't have any effect (for
> obvious reasons).  It's documented in the manpage.
> 
> In other words, the primaries -prune and -delete
> are mutual exclusive.  It could be argued whether
> find(1) should print a warning in that case.

It might be better documented, also.

So the bug that I'm *really* trying to scratch is in
/etc/periodic/daily/100.clean-disks:


            rc=$(find / \( ! -fstype local -o -fstype rdonly \) -a -prune -o \
                \( $args \) -atime +$daily_clean_disks_days -delete $print |
                tee /dev/stderr | wc -l)

where it's using -prune and -delete in the same call to find.

So I'll see if I can patch this, and file *that* bug report.

   Thanks again,
   <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.