From owner-freebsd-bugs Sun Dec 1 22: 0: 5 2002 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 2E48C37B401 for ; Sun, 1 Dec 2002 22:00:04 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D68AC43EB2 for ; Sun, 1 Dec 2002 22:00:03 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id gB2603x3035686 for ; Sun, 1 Dec 2002 22:00:03 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id gB2603ve035685; Sun, 1 Dec 2002 22:00:03 -0800 (PST) Date: Sun, 1 Dec 2002 22:00:03 -0800 (PST) Message-Id: <200212020600.gB2603ve035685@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: David Schultz Subject: Re: bin/45723: ls(1)'s wrong behaviour with not searchable directories Reply-To: David Schultz 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 The following reply was made to PR bin/45723; it has been noted by GNATS. From: David Schultz To: "Jose M. Alcaide" Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: bin/45723: ls(1)'s wrong behaviour with not searchable directories Date: Sun, 1 Dec 2002 21:52:40 -0800 > When a directory does not have search (x) permission, but it still have read > permission, its contents must be visible with "ls" (even "ls -i" should show > the inode numbers). However, FreeBSD's ls(1) does not show anything. Besides > that, a "ls -l" should fail, because search permission is required in order > to access the inode contents of the files in the directory; however, "ls -l" > gives nothing: no listing, no error message, nothing. > > >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. > $ ls -l FOOBAR > Yes, this is still broken. I get the following in Solaris 8: dschultz@nova:~> ls -l foo | sed 's/^/*/' ls: foo/a: Permission denied ls: foo/b: Permission denied ls: foo/c: Permission denied ls: foo/d: Permission denied ls: foo/e: Permission denied *total 0 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. There is also a bug in ls whereby it fails to print the total if stat() fails on each directory entry. Technically it should print 0 for consistency's sake. BTW, tcsh's globbing (but not autocompletion) is also affected by the fts bug. Ash, which does not use fts, works fine. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message