From nobody@FreeBSD.org  Thu Jan  4 12:26:16 2007
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 429EA16A707
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  4 Jan 2007 12:26:15 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [69.147.83.33])
	by mx1.freebsd.org (Postfix) with ESMTP id B286A13C428
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  4 Jan 2007 12:26:15 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id l04CQFd5028956
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 4 Jan 2007 12:26:15 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id l04CQF72028955;
	Thu, 4 Jan 2007 12:26:15 GMT
	(envelope-from nobody)
Message-Id: <200701041226.l04CQF72028955@www.freebsd.org>
Date: Thu, 4 Jan 2007 12:26:15 GMT
From: Ricardo Branco<goabranco@hotmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: /bin/ls bug
X-Send-Pr-Version: www-3.0

>Number:         107515
>Category:       bin
>Synopsis:       [patch] ls(1) bug
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    jh
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jan 04 12:30:11 GMT 2007
>Closed-Date:    Thu Mar 25 16:51:30 UTC 2010
>Last-Modified:  Thu Mar 25 16:51:30 UTC 2010
>Originator:     Ricardo Branco
>Release:        6.2-PRERELEASE & 5.4-RELEASE
>Organization:
>Environment:
FreeBSD orion 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Tue Jan  2 04:51:18 VET 2007     root@orion:/usr/obj/usr/src/sys/CUSTOM-3  i386
>Description:
Why is it that /bin/ls has the following behavior?

$ mkdir /tmp/a
$ chmod 000 /tmp/a
$ ls  /tmp/a/
ls: : Permission denied
$ ls /tmp/a
ls: a: Permission denied

I think the most sensible way is to use basename() and use the last component for the error message rather than just printing whatever exists after the last slash... 
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: remko 
State-Changed-When: Thu Jan 4 12:36:42 UTC 2007 
State-Changed-Why:  
I am sorry but this is not a bug, the behaviour is to list the contents 
of the directory if you request the leaf ( /tmp/a/ ) and to show the 
directory itself if you request that (/tmp/a). This is desired 
functionality and should not change imo. Thus closing the ticket, thanks 
for your willingness to improve FreeBSD though 

http://www.freebsd.org/cgi/query-pr.cgi?pr=107515 

From: David Taylor <davidt@yadt.co.uk>
To: Remko Lodder <remko@FreeBSD.org>
Cc: goabranco@hotmail.com, freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/107515: /bin/ls bug
Date: Thu, 4 Jan 2007 14:38:24 +0000

 On Thu, 04 Jan 2007, Remko Lodder wrote:
 > Synopsis: /bin/ls bug
 > 
 > State-Changed-From-To: open->closed
 > State-Changed-By: remko
 > State-Changed-When: Thu Jan 4 12:36:42 UTC 2007
 > State-Changed-Why: 
 > I am sorry but this is not a bug, the behaviour is to list the contents
 > of the directory if you request the leaf ( /tmp/a/ ) and to show the
 > directory itself if you request that (/tmp/a). This is desired
 > functionality and should not change imo.
 
 Unfortunately that is not the behaviour exhibited by ls.  Further,
 that was not the problem being reported, either.
 
 Both "ls /tmp/a/" and "ls /tmp/a" attempt to list the contents of the
 directory (as shown by the "Permission Denied" error.  The directory
 itself can by listed using "ls -d /tmp/a/" (or "ls -d /tmp/a").
 
 The actual bug being reported is a different matter, however:
 
 $ ls /tmp/a/
 ls: : Permission denied
   ^^^
 
 The name should not be blank here, it should be something like:
 
 $ ls /tmp/a
 ls: a: Permission denied
   ^^^^
 
 -- 
 David Taylor

From: Bruce Evans <bde@zeta.org.au>
To: David Taylor <davidt@yadt.co.uk>
Cc: freebsd-gnats-submit@freebsd.org, yar@freebsd.org
Subject: Re: bin/107515: /bin/ls bug
Date: Fri, 5 Jan 2007 10:50:12 +1100 (EST)

 On Thu, 4 Jan 2007, David Taylor wrote:
 
 > On Thu, 04 Jan 2007, Remko Lodder wrote:
 > > I am sorry but this is not a bug, the behaviour is to list the contents
 > > of the directory if you request the leaf ( /tmp/a/ ) and to show the
 > > directory itself if you request that (/tmp/a). This is desired
 > > functionality and should not change imo.
 >
 > Unfortunately that is not the behaviour exhibited by ls.  Further,
 > that was not the problem being reported, either.
 >
 > Both "ls /tmp/a/" and "ls /tmp/a" attempt to list the contents of the
 > directory (as shown by the "Permission Denied" error.  The directory
 > itself can by listed using "ls -d /tmp/a/" (or "ls -d /tmp/a").
 >
 > The actual bug being reported is a different matter, however:
 >
 > $ ls /tmp/a/
 > ls: : Permission denied
 >   ^^^
 >
 > The name should not be blank here, it should be something like:
 >
 > $ ls /tmp/a
 > ls: a: Permission denied
 >   ^^^^
 
 Both of these behaviours are bugs.  The pathname with the problem is
 /tmp/a or /tmp/a/.  ls should be reporting that.  Instead, ls apparently
 does extra work to mess up the pathname, and gets it completely wrong
 for the one with the trailing slash.  Truss output:
 
 ls /tmp/a:
 %%%
 ...
 stat("/tmp/a",0xbfbfe230)			 = 0 (0x0)
 open(".",0x0,00)				 = 3 (0x3)
 fchdir(0x3)					 = 0 (0x0)
 stat("/tmp/a",0xbfbfe1e0)			 = 0 (0x0)
 open("/tmp/a",0x4,00)				 ERR#13 'Permission denied'
 stat("/tmp/a",0xbfbfe1e0)			 = 0 (0x0)
 open("/tmp/a",0x4,00)				 ERR#13 'Permission denied'
 ls: write(2,0xbfbfdb70,4)				 = 4 (0x4)
 a: Permission deniedwrite(2,0xbfbfdb90,20)				 = 20 (0x14)
 %%%
 
 ls /tmp/a/
 %%%
 ...
 stat("/tmp/a/",0xbfbfe230)			 = 0 (0x0)
 open(".",0x0,00)				 = 3 (0x3)
 fchdir(0x3)					 = 0 (0x0)
 stat("/tmp/a/",0xbfbfe1e0)			 = 0 (0x0)
 open("/tmp/a/",0x4,00)				 ERR#13 'Permission denied'
 stat("/tmp/a/",0xbfbfe1e0)			 = 0 (0x0)
 open("/tmp/a/",0x4,00)				 ERR#13 'Permission denied'
 ls: write(2,0xbfbfdb70,4)				 = 4 (0x4)
 : Permission deniedwrite(2,0xbfbfdb90,19)				 = 19 (0x13)
 %%%
 
 It works with the full pathname throughout, then apparently tries to
 print the basename.  basename(1) and presumably basename(3) give a
 basename of "a" for both, but ls gets the trailing slash stripping
 wrong and prints "" for /tmp/a/.
 
 It may be wrong for basename(3) to strip the slash too (since stripping
 the slash is wrong if the path is a symlink), but this is the historical
 behaviour and POSIX requries it.  Thus utilities should be careful about
 using basename(3) if there might be a symlink involved.  ls's bug with
 a symlinked variant of the unreadable directory is a little different:
 
 Setup:
 %%%
 d---------  2 bde  wheel  512 Jan  5 09:41 a
 lrwxr-xr-x  1 bde  wheel    1 Jan  5 10:08 b -> a
 %%%
 
 ls /tmp/b:
 %%%
 ...
 open("/tmp/b",0x4,00)				 ERR#13 'Permission denied'
 ls: write(2,0xbfbfdb70,4)				 = 4 (0x4)
 b: Permission deniedwrite(2,0xbfbfdb90,20)				 = 20 (0x14)
 %%%
 
 Now "b" is perfectly readable, but what it points to isn't.  It is hard for
 ls to print anything better than /tmp/b in the error message, since it
 only tried to access the latter.
 
 ls /tmp/b/:
 %%%
 ...
 open("/tmp/b/",0x4,00)				 ERR#13 'Permission denied'
 ls: write(2,0xbfbfdb70,4)				 = 4 (0x4)
 : Permission deniedwrite(2,0xbfbfdb90,19)				 = 19 (0x13)
 %%%
 
 Same bug as for ls /tmp/b/.  Even more confusing now.
 
 The case of ls -R broken in a slightly different way:
 
 ls -R /tmp (where /tmp contains "a" and "b" as above):
 %%%
 ...
 open("a",0x4,027757761130)			 ERR#13 'Permission denied'
 ls: write(2,0xbfbfdb70,4)				 = 4 (0x4)
 a: Permission deniedwrite(2,0xbfbfdb90,20)				 = 20 (0x14)
 %%%
 
 As usual, ls cannot open "a", and it prints only "a" in the error message,
 but the full path is much more needed for recursive listings since it might
 be anywhere in the tree.
 
 Incomplete fix (ls isn't actually doing extra work to get this wrong):
 %%%
 Index: ls.c
 ===================================================================
 RCS file: /home/ncvs/src/bin/ls/ls.c,v
 retrieving revision 1.78
 diff -u -2 -r1.78 ls.c
 --- ls.c	8 Jun 2004 09:30:10 -0000	1.78
 +++ ls.c	4 Jan 2007 23:30:52 -0000
 @@ -477,5 +477,5 @@
   		case FTS_DNR:
   		case FTS_ERR:
 -			warnx("%s: %s", p->fts_name, strerror(p->fts_errno));
 +			warnx("%s: %s", p->fts_path, strerror(p->fts_errno));
   			rval = 1;
   			break;
 %%%
 
 This prints the full path in the error message for the unreadable directory
 (FTS_DNR) case and in some other cases.
 
 Other things to fix:
 - ls prints only fts_name in many other messages.  I think this is only
    sometimes correct.  E.g., it is normal the output format for ls -R.
    (However I rarely use ls -R since this format is hard to unimprove on.)
 - I think it is a bug in fts(3) for fts_path to be empty.  The empty
    pathname is never valid, and the error is for the directory.  Apparently,
    fts(3) reduces /tmp/a/ to the invalid basename "", but does the right
    thing for /tmp/a.
 
 Bruce
State-Changed-From-To: closed->open 
State-Changed-By: remko 
State-Changed-When: Fri Jan 5 06:35:44 UTC 2007 
State-Changed-Why:  
I was wrong in the assumption that this is desired behaviour, 
Bruce has posted a nice explanation for this. Reopen the 
ticket. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=107515 

From: "Ighighi Ighighi" <ighighi@gmail.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/107515: ls(1) bug
Date: Sat, 23 Jun 2007 04:13:19 -0400

 Bruce Evans wrote:
 >  I think it is a bug in fts(3) for fts_path to be empty.  The empty
 >  pathname is never valid, and the error is for the directory.  Apparently,
 >  fts(3) reduces /tmp/a/ to the invalid basename "", but does the right
 >  thing for /tmp/a.
 
 Well, there's a 2 years old patch in OpenBSD applied in the same place
 as yours, titled
 "use fts_path if fts_name is not available", so it seems there are
 cases where fts_name
 could be "", the code in fts.c is theirs after all.  Check:
 
 http://www.openbsd.org/cgi-bin/cvsweb/src/bin/ls/ls.c.diff?r1=1.22&r2=1.23
 http://www.openbsd.org/cgi-bin/cvsweb/src/bin/ls/ls.c
 
 Maybe it's time to patch this one.
Responsible-Changed-From-To: freebsd-bugs->jh 
Responsible-Changed-By: jh 
Responsible-Changed-When: Fri Jan 8 08:05:08 UTC 2010 
Responsible-Changed-Why:  
Take. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=107515 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/107515: commit references a PR
Date: Sun, 24 Jan 2010 19:17:45 +0000 (UTC)

 Author: jh
 Date: Sun Jan 24 19:17:35 2010
 New Revision: 202944
 URL: http://svn.freebsd.org/changeset/base/202944
 
 Log:
   Print full path in the error message. It's possible that fts(3)
   provides an empty fts_name and reporting the full path is more
   appropriate especially with the -R option.
   
   PR:		bin/107515
   Submitted by:	bde
   Approved by:	trasz (mentor)
   MFC after:	1 week
 
 Modified:
   head/bin/ls/ls.c
 
 Modified: head/bin/ls/ls.c
 ==============================================================================
 --- head/bin/ls/ls.c	Sun Jan 24 19:11:08 2010	(r202943)
 +++ head/bin/ls/ls.c	Sun Jan 24 19:17:35 2010	(r202944)
 @@ -508,7 +508,7 @@ traverse(int argc, char *argv[], int opt
  			break;
  		case FTS_DNR:
  		case FTS_ERR:
 -			warnx("%s: %s", p->fts_name, strerror(p->fts_errno));
 +			warnx("%s: %s", p->fts_path, strerror(p->fts_errno));
  			rval = 1;
  			break;
  		case FTS_D:
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: open->patched 
State-Changed-By: jh 
State-Changed-When: Sun Jan 24 19:33:15 UTC 2010 
State-Changed-Why:  
Patched in head (r202944). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=107515 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/107515: commit references a PR
Date: Sun, 31 Jan 2010 15:07:47 +0000 (UTC)

 Author: jh
 Date: Sun Jan 31 15:07:38 2010
 New Revision: 203291
 URL: http://svn.freebsd.org/changeset/base/203291
 
 Log:
   MFC r202944:
   
   Print full path in the error message. It's possible that fts(3)
   provides an empty fts_name and reporting the full path is more
   appropriate especially with the -R option.
   
   PR:		bin/107515
   Approved by:	trasz (mentor)
 
 Modified:
   stable/8/bin/ls/ls.c
 Directory Properties:
   stable/8/bin/ls/   (props changed)
 
 Modified: stable/8/bin/ls/ls.c
 ==============================================================================
 --- stable/8/bin/ls/ls.c	Sun Jan 31 14:51:04 2010	(r203290)
 +++ stable/8/bin/ls/ls.c	Sun Jan 31 15:07:38 2010	(r203291)
 @@ -508,7 +508,7 @@ traverse(int argc, char *argv[], int opt
  			break;
  		case FTS_DNR:
  		case FTS_ERR:
 -			warnx("%s: %s", p->fts_name, strerror(p->fts_errno));
 +			warnx("%s: %s", p->fts_path, strerror(p->fts_errno));
  			rval = 1;
  			break;
  		case FTS_D:
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/107515: commit references a PR
Date: Thu, 25 Mar 2010 16:31:20 +0000 (UTC)

 Author: jh
 Date: Thu Mar 25 16:31:05 2010
 New Revision: 205648
 URL: http://svn.freebsd.org/changeset/base/205648
 
 Log:
   MFC r202944:
   
   Print full path in the error message. It's possible that fts(3)
   provides an empty fts_name and reporting the full path is more
   appropriate especially with the -R option.
   
   PR:		bin/107515
 
 Modified:
   stable/7/bin/ls/ls.c
 Directory Properties:
   stable/7/bin/ls/   (props changed)
 
 Modified: stable/7/bin/ls/ls.c
 ==============================================================================
 --- stable/7/bin/ls/ls.c	Thu Mar 25 15:56:04 2010	(r205647)
 +++ stable/7/bin/ls/ls.c	Thu Mar 25 16:31:05 2010	(r205648)
 @@ -504,7 +504,7 @@ traverse(int argc, char *argv[], int opt
  			break;
  		case FTS_DNR:
  		case FTS_ERR:
 -			warnx("%s: %s", p->fts_name, strerror(p->fts_errno));
 +			warnx("%s: %s", p->fts_path, strerror(p->fts_errno));
  			rval = 1;
  			break;
  		case FTS_D:
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: patched->closed 
State-Changed-By: jh 
State-Changed-When: Thu Mar 25 16:51:29 UTC 2010 
State-Changed-Why:  
Fixed in head, stable/8 and stable/7. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=107515 
>Unformatted:
