bin/47333: stat -L undocumented behavior

[tobiasu%tmux.org@localhost]

>Number:         47333
>Category:       bin
>Synopsis:       stat -L undocumented behavior
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Dec 15 15:25:01 +0000 2012
>Originator:     Tobias Ulmer
>Release:        
>Organization:
>Environment:
>Description:
"stat -L" claims to "Use stat(2) instead of lstat(2).  The information reported 
by stat will refer to the target of file, if file is a symbolic link, and not 
to file itself."

This is fine, and could for example be used to detect broken symlinks. Except 
it's not what it does. In case of a broken symlink it will fall back to 
lstat(2) and return the symlink info.

The only way to figure this out would be to compare the output of stat (without 
-L) or realize that symlinks can't show up with "stat -L" - and it must be 
broken (which requires one to be well caffeinated!).

The change was introduced quite some time ago:
http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/stat/stat.c?only_with_tag=MAIN#rev1.18

I argue that this should be reverted. Going by the very explicit documentation, 
the code is in error. Aside from that, stat(1) seems to be a designed as a 
simple scriptable wrapper around stat(2), not a higher-level tool like find(1) 
with all sorts of smarts. It makes scripting harder, because you either don't 
want to hear about symlinks at all, or you are interested in broken symlinks 
and would like to do something based on that information.

So, what does everyone else do? GNU stat prints an error message (-L is one of 
the few "standard" options). FreeBSD and OpenBSD use NetBSD's stat.
>How-To-Repeat:
ln -s doesnotexist foo
stat -L foo
<stat should print errno and return != 0>
>Fix:
Revert 
http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/stat/stat.c.diff?r1=1.17&r2=1.18&only_with_tag=MAIN