From owner-svn-src-head@FreeBSD.ORG Wed Feb 17 18:47:23 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88A3B106566C; Wed, 17 Feb 2010 18:47:23 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 1FD838FC1D; Wed, 17 Feb 2010 18:47:22 +0000 (UTC) Received: from c122-106-163-215.carlnfd1.nsw.optusnet.com.au (c122-106-163-215.carlnfd1.nsw.optusnet.com.au [122.106.163.215]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o1HIlKZ4023649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Feb 2010 05:47:21 +1100 Date: Thu, 18 Feb 2010 05:47:19 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Poul-Henning Kamp In-Reply-To: <201002170911.o1H9BL6m095996@svn.freebsd.org> Message-ID: <20100218044931.S95007@delplex.bde.org> References: <201002170911.o1H9BL6m095996@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r203990 - head/lib/libc/sys X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 18:47:23 -0000 On Wed, 17 Feb 2010, Poul-Henning Kamp wrote: > Log: > Mention EISDIR as a possible errno. It's not a possible error. > Modified: > head/lib/libc/sys/unlink.2 > > Modified: head/lib/libc/sys/unlink.2 > ============================================================================== > --- head/lib/libc/sys/unlink.2 Wed Feb 17 09:09:12 2010 (r203989) > +++ head/lib/libc/sys/unlink.2 Wed Feb 17 09:11:21 2010 (r203990) > @@ -114,6 +114,8 @@ succeeds unless: > .Bl -tag -width Er > .It Bq Er ENOTDIR > A component of the path prefix is not a directory. > +.It Bq Er EISDIR > +The named file is a directory. > .It Bq Er ENAMETOOLONG > A component of a pathname exceeded 255 characters, > or an entire path name exceeded 1023 characters. According to the POSIX spec (old draft, current version is the same): %%% 48397 [EPERM] The file named by path is a directory, and either the calling process does not 48398 have appropriate privileges, or the implementation prohibits using unlink( ) 48399 on directories. [EISDIR] [not mentioned for unlink()] %%% According to unlink.2: %%% [EPERM] The named file is a directory. [EISDIR] [previously not mentioned] %%% According to the source code: in kern_unlinkat(): % if (vp->v_type == VDIR && oldinum == 0) { % error = EPERM; /* POSIX */ % } else if (oldinum != 0 && % ((error = vn_stat(vp, &sb, td->td_ucred, NOCRED, td)) == 0) && % sb.st_ino != oldinum) { % error = EIDRM; /* Identifier removed */ % } else { `oldinum' is always 0 for unlink(2). Thus the code matches the specified and previously-documented behaviour. FreeBSD is still choosing to implement the second possibility of the spec (that the implementation prohibits using unlink() on directories) (except the first possibility allows this too -- appropriate privilege can mean "more privilege than anyone has"). The difference may be a difference in FreeBSD since trying to use appropriate privilege may have side effects, but it isn't required to be a difference in POSIX. `oldinum' is also always 0 for unlinkat(2). It seems to be only nonzero for the ffs_fsck sysctl. I guess this sysctl is undocumented and its EIDRM error is even less documented. The oldinum code has bad style: - weird indentation for both continued lines. Far from KNF (-ci4). Closer to -lp, but off-by 1 char for that. - banal comment. The "POSIX" comment for oldinum == 0 is banal and misleading too. POSIX does specify the errno as EPERM, but the only possibly-surprising thing about this errno is that it occurs for the superuser too, not what it is. Once upon a time, FreeBSD implemented the first possibility, with appropriate privilege meaning that only the superuser can try to unlink() (might still fail due to a leaf file system not liking it). Then the errno of EPERM was generic for lack of appropriate privelege and not commented on. Only the superuse case changed, and the comment misleads by documenting something banal instead of that. Bruce