+++ This bug was initially created as a clone of Bug #230052 +++

Description of problem:

ls -lL displays dangling symlinks with full path.

Version-Release number of selected component (if applicable):
coreutils-5.97-12.2.fc6


How reproducible:
always

Steps to Reproduce:
  
dixsept /tmp $ mkdir a ; touch a/b ; ln -s d a/c ; ls -lL a
total 0
?--------- ? ?     ?      ?            ? a/c
-rw-r--r-- 1 thome spaces 0 Feb 26 11:42 b
dixsept /tmp $ touch a/d ; ls -lL a
total 0
-rw-r--r-- 1 thome spaces 0 Feb 26 11:42 b
-rw-r--r-- 1 thome spaces 0 Feb 26 11:42 c
-rw-r--r-- 1 thome spaces 0 Feb 26 11:42 d

Expected results:

The question marks aren't really a problem. However I find it quite odd to have
``a/c'' displayed in the first example, while I would have expected a plain ``c''.

Previous versions of coreutils failed with ``a/c: No such file or directory''.
It's neat to still display the file, but it would be even better to have the
basename displayed.


Additional info:

Might be NOTABUG if there's a good rationale for it...

-- Additional comment from meyering on 2007-02-26 05:56 EST --
Thanks for the report.
FYI, this is fixed in newer versions.
With coreutils-6.7-8.fc7, I get this:

    $ mkdir a ; touch a/b ; ln -s d a/c ; /bin/ls -lL a
    /bin/ls: cannot access a/c: No such file or directory
    total 0
    -rw-r--r-- 1 meyering meyering 0 Feb 26 11:53 b
    l????????? ? ?        ?        ?            ? c


-- Additional comment from twaugh on 2007-02-26 06:23 EST --
I'll add this to the list of things to backport to FC-6.

-- Additional comment from meyering on 2007-02-26 06:40 EST --
Thanks, Tim.
BTW, here's the upstream patch that fixed it:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=9e0a095be64

-- Additional comment from twaugh on 2007-04-17 07:48 EST --
Actually it turned out that the real bug was in the SELinux patch.  Here is that
fix:

--- coreutils-5.97/src/ls.c     2006-10-03 17:18:16.000000000 +0100
+++ coreutils-5.97/src/ls.c     2006-10-03 17:18:16.000000000 +0100
@@ -2690,7 +2690,7 @@
          f->filetype = type;
          memset (&f->stat, '\0', sizeof (f->stat));
 
-         f->name = xstrdup (absolute_name);
+         f->name = xstrdup (name);
          files_index++;
 
          return 0;