bug#12445: ls --color does not color symlinks when not resolving them

[Matei David]

On Sat, 15 Sep 2012 00:55:12 +0100
Pádraig Brady <address@hidden> wrote:

> tag 12445 + notabug
> close 12445
> stop
> 
> On 09/14/2012 05:54 PM, Matei David wrote:
> > When the ORPHAN property is disabled in dircolors, ls --color does not
> > stat() symlinks. However, in this case symlinks are not colored using the
> > LINK property.
> >
> > How to reproduce:
> > $ eval $(dircolors -p | sed 's/^ORPHAN.*/ORPHAN 00/' | dircolors -)
> > $ mkdir /tmp/xxx
> > $ ln -s /tmp/nowhere /tmp/xxx/yyy
> > $ ls --color /tmp/xxx
> >
> > Expected output:
> > yyy, colored cyan (default for LINK)
> >
> > Actual output:
> > yyy, not colored
> >
> > Fix attached. Basically, in gobble_file(), assume a symlink is ok if stat()
> > is not run on it.
> 
> It seems this was fixed over 5 years ago in version 6.9
> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=0a744370
> Are you using an older version than that?
> 
> I'm marking as done for now.
> 
> thanks,
> Pádraig.

I'm using coreutils 8.19. There are 2 lines which ever modify f->linkok (both
set it to true): 2700 and 2720. Both are inside the if block starting at
line 2560. By design, the if block is _not_ executed under the conditions I laid
out above in order to avoid both fstat() and stat() calls on the symlink (which
is ok!) However, the coloring is missing. Did you try my code?

The bug you mention was about avoiding the stat() call, i.e. following the
link. There is also this one, related:
http://git.savannah.gnu.org/cgit/coreutils.git/commit/src/ls.c?id=a085b6fc6c8fa03dac20f01f2f2b64b50b8bdf66

The behaviour I observe is: no fstat(), no stat(), (great so far...) but no
color either- that's the bug.