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...
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
I'll add this to the list of things to backport to FC-6.
Thanks, Tim. BTW, here's the upstream patch that fixed it: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=9e0a095be64
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;
Fixed in update: coreutils-5.97-12.5.fc6