Date: Sun, 21 Oct 2007 18:40:02 GMT From: Romain =?iso-8859-1?Q?Tarti=E8re?= <romain@blogreen.org> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/90687: [patch] side effect of -delete option of find(1) Message-ID: <200710211840.l9LIe2v7027199@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/90687; it has been noted by GNATS.
From: Romain =?iso-8859-1?Q?Tarti=E8re?= <romain@blogreen.org>
To: bug-followup@FreeBSD.org, anatoli@aksoft.net
Cc:
Subject: Re: bin/90687: [patch] side effect of -delete option of find(1)
Date: Sun, 21 Oct 2007 20:08:49 +0200
--n8g4imXOkfNTN/H1
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
second.
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
wants.
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
Romain
--n8g4imXOkfNTN/H1
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
iD8DBQFHG5Wx2OmjP/9W/0MRAqWnAJ9en87vwKJ/cWFbNArLOm3rBkwY/wCfemb2
Q+fpZAYLuqnCydfS199ThfI=
=He+u
-----END PGP SIGNATURE-----
--n8g4imXOkfNTN/H1--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200710211840.l9LIe2v7027199>