From owner-freebsd-bugs Mon Dec 2 1:45:31 2002 Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B532937B401 for ; Mon, 2 Dec 2002 01:45:29 -0800 (PST) Received: from HAL9000.homeunix.com (12-232-220-15.client.attbi.com [12.232.220.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id E214343ED1 for ; Mon, 2 Dec 2002 01:45:28 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id gB29jROK000558; Mon, 2 Dec 2002 01:45:27 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id gB29jRVL000557; Mon, 2 Dec 2002 01:45:27 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Mon, 2 Dec 2002 01:45:27 -0800 From: David Schultz To: Bruce Evans Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: bin/45723: ls(1)'s wrong behaviour with not searchable directories Message-ID: <20021202094527.GA398@HAL9000.homeunix.com> Mail-Followup-To: Bruce Evans , freebsd-bugs@FreeBSD.ORG References: <200212020600.gB2603ve035685@freefall.freebsd.org> <20021202182939.U3146-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021202182939.U3146-100000@gamplex.bde.org> Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thus spake Bruce Evans : > On Sun, 1 Dec 2002, David Schultz wrote: > > > > >How-To-Repeat: > > > $ mkdir FOOBAR > > > $ cd FOOBAR > > > $ touch a b c d e > > > $ cd .. > > > $ chmod -x FOOBAR > > > $ ls FOOBAR > > > > > > > This one seems to be fixed in -CURRENT. > > It is broken for me, but that is because I have ls aliased to ls -F. Yes, -G, -F, -l---basically anything that requires ls to stat the files---will trigger the bug. > > The problem appears to be in the fts_children() implementation. > > If a chdir fails, the routine does not retry with FTS_NOCHDIR as > > it should... > > I think fts it must honor FTS_NOCHDIR. ls could retry. But chdir > is essential for handling deep directories. Most utilities that > use FTS_NOCHDIR are simply broken since they should or shall support > deep directories but don't. cp is the most important one. I'm not suggesting that it ignore FTS_NOCHDIR, but rather that it fall back to the FTS_NOCHDIR behavior when it lacks search permission. Deeply dested directories are a non-issue here (modulo one path component) because without search permission, you can't descend further into the heirarchy anyway. BTW, FTS already fails to honor (the lack of) FTS_NOCHDIR if you pass FTS_LOGICAL as a flag to fts_open(), and when it fails to open ".". If you fix the problem in ls, you'll also have to fix it in tcsh, maybe rm, and many other utilities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message