From owner-freebsd-bugs@FreeBSD.ORG Sun Oct 21 18:40:03 2007 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5091916A41B for ; Sun, 21 Oct 2007 18:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 52C3313C480 for ; Sun, 21 Oct 2007 18:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l9LIe3fQ027200 for ; Sun, 21 Oct 2007 18:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l9LIe2v7027199; Sun, 21 Oct 2007 18:40:02 GMT (envelope-from gnats) Date: Sun, 21 Oct 2007 18:40:02 GMT Message-Id: <200710211840.l9LIe2v7027199@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Romain =?iso-8859-1?Q?Tarti=E8re?= Cc: Subject: Re: bin/90687: [patch] side effect of -delete option of find(1) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Romain =?iso-8859-1?Q?Tarti=E8re?= List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2007 18:40:03 -0000 The following reply was made to PR bin/90687; it has been noted by GNATS. From: Romain =?iso-8859-1?Q?Tarti=E8re?= 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--