bin/90687: [patch] side effect of -delete option of find(1)

Romain Tartière romain at
Sun Oct 21 11:40:03 PDT 2007

The following reply was made to PR bin/90687; it has been noted by GNATS.

From: Romain =?iso-8859-1?Q?Tarti=E8re?= <romain at>
To: bug-followup at, anatoli at
Subject: Re: bin/90687: [patch] side effect of -delete option of find(1)
Date: Sun, 21 Oct 2007 20:08:49 +0200

 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 The find manpage says:
 > The find utility recursively descends the directory tree for each
 > _pathname_ listed, evaluating an _expression_ (composed of the
 > ``primaries'' and ``operands'' listed below) in terms of each file in
 > the tree.
 Most operands return True or False depending on the nature of a found
 file (i.e. -nouser: True if the file belongs to an unknown user), other
 performs actions (i.e -print: This primary always evaluates to true.  It
 prints the pathname of the current file to standard output).
 The -delete operand also return true all the time.  In other word, as
 -print or -delete are just two operands that return true, we can expect
 an expression using the first or the second act on the same files,
 displaying filenames for the first case, and deleting files for the
 According to me, silently disabling symbolic links following depending
 on witch operands are set looks odd.  In fact, if I am not sure of what
 I am doing, I may first run find with a -print operand, and if
 everything is okay, then replace -print with -delete.  It is exactly
 what I did after reading the man page example regarding the "Delete all
 broken symbolic links in /usr/ports/packages".  I got 2-3 broken links
 as a result and so confidently replaced -print by -delete to actually do
 the job. I basically see all this as a ``for'' loop that behaves
 differently depending on what is performed in the without-side-effects
 loop block.
 Moreover, 1.8 revision (introduction of the -delete operand) commit
 message states that "the code is extremely paranoid", consider race
 condition, etc.  But the behaviour of find is to not traverse symbolic
 links if not told otherwise.  In other word, it will have the same
 behaviour as rm: considering symbolic links, not referenced files, and
 does not fills the requirements for a symbolic link race condition. So
 maybe the tool may be less paranoid and only the paranoidness of the
 user may be taken into account?
 Without the restriction told about here, find would be a good tool to
 delete particular files according to random criteria (and then the
 -delete operand makes sense).
 At least, if for ``security reasons'' we don't want the user to use -L
 and -delete at the same time, we'd better raise an error and do nothing:
 "find: -L and -delete cannot be used simultaneously"
 ... or even sort of a -shoot-me-in-the-foot option to force find to do
 ``risky'' stuff rather than doing something the user probably doesn't
 BTW, for those who reached the PR page after deleting a brunch of
 symlinks in /usr/ports/packages, you can resurrect them with:
 # for PORT in `pkg_info -q -a -o`; do cd /usr/ports/$PORT && \
                                       make package-links; done
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 Version: GnuPG v2.0.4 (FreeBSD)

More information about the freebsd-bugs mailing list