NetBSD Problem Report #47333

From www@NetBSD.org  Sat Dec 15 15:20:55 2012
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 9BBBC63E529
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 15 Dec 2012 15:20:55 +0000 (UTC)
Message-Id: <20121215152054.AA92C63E529@www.NetBSD.org>
Date: Sat, 15 Dec 2012 15:20:54 +0000 (UTC)
From: tobiasu@tmux.org
Reply-To: tobiasu@tmux.org
To: gnats-bugs@NetBSD.org
Subject: stat -L undocumented behavior
X-Send-Pr-Version: www-1.0

>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
>Last-Modified:  Sat Dec 15 21:00:05 +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

>Audit-Trail:
From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
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 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.

 	David

 -- 
 David Laight: david@l8s.co.uk

From: Tobias Ulmer <tobiasu@tmux.org>
To: gnats-bugs@NetBSD.org
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>
 > To: gnats-bugs@NetBSD.org
 > 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 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
 >  

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/47333: stat -L undocumented behavior
Date: Sat, 15 Dec 2012 20:02:35 +0000

 On Sat, Dec 15, 2012 at 04:30:13PM +0000, David Laight wrote:
  >  On Sat, Dec 15, 2012 at 03:25:01PM +0000, tobiasu@tmux.org 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.

 Please check the standards (since this is where this program came
 from, it isn't either native or historical) before proposing things
 like this.

 -- 
 David A. Holland
 dholland@netbsd.org

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

 On Sat, Dec 15, 2012 at 08:05:02PM +0000, David Holland wrote:
 > The following reply was made to PR bin/47333; it has been noted by GNATS.
 > 
 > From: David Holland <dholland-bugs@netbsd.org>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: bin/47333: stat -L undocumented behavior
 > Date: Sat, 15 Dec 2012 20:02:35 +0000
 > 
 >  On Sat, Dec 15, 2012 at 04:30:13PM +0000, David Laight wrote:
 >   >  On Sat, Dec 15, 2012 at 03:25:01PM +0000, tobiasu@tmux.org 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.
 >  
 >  Please check the standards (since this is where this program came
 >  from, it isn't either native or historical) before proposing things
 >  like this.

 After a bit more digging, it turns out that the original stat was
 devised by Michael Meskes. It was later integrated into coreutils.

 See here for history:
 http://fossies.org/linux/misc/stat-3.3.tar.gz:a/stat-3.3/README

 >  
 >  -- 
 >  David A. Holland
 >  dholland@netbsd.org
 >  

Home	PR Database Search