From owner-freebsd-bugs@FreeBSD.ORG Tue Dec 20 23:30:10 2005 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C388016A41F for ; Tue, 20 Dec 2005 23:30:10 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51A1243D5A for ; Tue, 20 Dec 2005 23:30:10 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id jBKNUAXB040617 for ; Tue, 20 Dec 2005 23:30:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id jBKNUAna040615; Tue, 20 Dec 2005 23:30:10 GMT (envelope-from gnats) Date: Tue, 20 Dec 2005 23:30:10 GMT Message-Id: <200512202330.jBKNUAna040615@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Parv 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: Parv List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2005 23:30:10 -0000 The following reply was made to PR bin/90687; it has been noted by GNATS. From: Parv To: Anatoli Klassen Cc: FreeBSD-gnats-submit@FreeBSD.org Subject: Re: bin/90687: [patch] side effect of -delete option of find(1) Date: Tue, 20 Dec 2005 18:29:42 -0500 in message <20051220145417.1B52D1DA14@26th.net>, wrote Anatoli Klassen thusly... > > > >Environment: > System: FreeBSD mercury.26th.net 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #0: Wed Jul 27 12:58:07 CEST 2005 root@mercury.26th.net:/usr/obj/usr/src/sys/MERCURY i386 > > >Description: > If -delete option is used it cancel -L option silently. So find does > something different as it does with just -print option. The result could be > deleting of all symbolic links instead of broken ones only even if user has > already validated this with previous -print run. > > >How-To-Repeat: > Create a file, symbolic link to it and a broken symbolic link: > touch a && ln -s a b && ln -s c d > > Now detect all broken links: > find -L . -type l > - works fine, shows that "d" is broken. > > Then try to delete the broken links > find -L . -type l -delete > - all links are deleted, not only broken ones. In your example above ... - "b" & "d" are found due to "-type l" criteria, - information about "a" is returned, instead of "b", due to "-L" option - file information about "a" is suppressed as it is not a link, - information about "d" is returned as it is a link and and the linked file does not exist. - in the end, all you have is "d" in the output. Refer to "-L" option description ... -L Cause the file information and file type (see stat(2)) returned for each symbolic link to be those of the file referenced by the link, not the link itself. If the referenced file does not exist, the file information and type will be for the link itself. - Parv --