Re: bin/47333: stat -L undocumented behavior

[Tobias Ulmer <tobiasu%tmux.org@localhost>]

The following reply was made to PR bin/47333; it has been noted by GNATS.

From: Tobias Ulmer <tobiasu%tmux.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: bin/47333: stat -L undocumented behavior
Date: Sat, 15 Dec 2012 19:13:17 +0100

 On Sat, Dec 15, 2012 at 04:30:13PM +0000, David Laight wrote:
 > The following reply was made to PR bin/47333; it has been noted by GNATS.
 > 
 > From: David Laight <david%l8s.co.uk@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc: 
 > Subject: Re: bin/47333: stat -L undocumented behavior
 > Date: Sat, 15 Dec 2012 16:43:47 +0000
 > 
 >  On Sat, Dec 15, 2012 at 03:25:01PM +0000, tobiasu%tmux.org@localhost wrote:
 >  > >Number:         47333
 >  > >Category:       bin
 >  > >Synopsis:       stat -L undocumented behavior
 >  ...
 >  > "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.
 >  
 >  So you can detect that by noticing that the output of 'stat -L' is
 >  still a symlink.
 >  
 >  The man page needs fixing.
 
 Yes, that is easy. Yes one can hack around it, but the whole point of -L
 is to use stat(2) - not lstat(2), right?  Also why be gratuitously
 incompatible with GNU stat? Is there an actual use case?
 
 Once it's documented, it would be very hard to remove again. For now
 it's simply a bug.
 
 >  
 >      David
 >  
 >  -- 
 >  David Laight: david%l8s.co.uk@localhost
 >