From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 6 17:23:12 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62D45106566B; Fri, 6 Nov 2009 17:23:12 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) by mx1.freebsd.org (Postfix) with ESMTP id C794C8FC0C; Fri, 6 Nov 2009 17:23:11 +0000 (UTC) Received: from [195.4.92.17] (helo=7.mx.freenet.de) by mout1.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1N6SWk-0002lF-DB; Fri, 06 Nov 2009 18:23:10 +0100 Received: from tc89e.t.pppool.de ([89.55.200.158]:55359 helo=ernst.jennejohn.org) by 7.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1N6SWk-0002g1-4e; Fri, 06 Nov 2009 18:23:10 +0100 Date: Fri, 6 Nov 2009 18:23:08 +0100 From: Gary Jennejohn To: Alexander Best Message-ID: <20091106182308.14dffc50@ernst.jennejohn.org> In-Reply-To: References: <20091106170853.7d0b0b6f@ernst.jennejohn.org> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Alex Dupre Subject: Re: rmdir(2) and mkdir(2) both return EISDIR for argument "/" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 17:23:12 -0000 On Fri, 06 Nov 2009 17:43:06 +0100 (CET) Alexander Best wrote: > Gary Jennejohn schrieb am 2009-11-06: > > On Fri, 06 Nov 2009 16:32:22 +0100 (CET) > > Alexander Best wrote: > > > > Alex Dupre schrieb am 2009-11-06: > > > > Alexander Best ha scritto: > > > > > i dug up this old pr > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/59739 > > > > > I think the EISDIR error is coming from kern/vfs_lookup.c, > > > > lookup() > > > > function with cn_nameptr = "": > > > > > > /* > > > > * Check for degenerate name (e.g. / or "") > > > > * which is a way of talking about a directory, > > > > * e.g. like "/." or ".". > > > > */ > > > > if (cnp->cn_nameptr[0] == '\0') { > > > > ... > > > > if (cnp->cn_nameiop != LOOKUP) { > > > > error = EISDIR; > > > > goto bad; > > > > } > > > > ... > > > > thanks a lot for finding the problem in the src. what do you think > > > of the > > > patch attached to this message? after applying it the example code > > > i posted in > > > my previous message returns the following output (instead of > > > EISDIR): > > > > rmdir errno: 16 (which is EBUSY) > > > mkdir errno: 17 (which is EEXIST) > > > > i don't know if these really are the correct return values, but > > > it's what the > > > originator of the PR requested. > > > > What if cn_nameiop is != LOOKUP but also neither DELETE nor CREATE, > > assuming that case is possible? I'd leave the original if-clause at > > the end to catch that. > > > --- > > Gary Jennejohn > > how about this patch? > > 1. i've added "if (cnp->cn_nameiop != LOOKUP)" although i don't think it's > necessary since the first blocks should cover all the possible cases. > 2. i've used rename() to test the case (cnp->cn_nameiop != RENAME). is this > correct or does rename() use a combo of DELETE and CREATE? problem is that the > rename(2) manual doesn't seem to cover the case that arg 1 is a mountpoint. > right now EBUSY gets returned if cnp->cn_nameiop != RENAME. however BUSY needs > to be added to all manuals which use cnp->cn_nameiop != RENAME (shouldn't be > too many). or are there any other suggestions what rename() should return if > arg 1 is a mountpoint? > Hmm. In rename(2) there's [EINVAL] The from argument is a parent directory of to, or an attempt is made to rename `.' or `..'. and a few lines below your patch this case is handled for ISDOTDOT for both RENAME and DELETE. I don't see off hand where renaming or deleting "." is handled. According to the comment above your patch the case of "/." or "." is being checked, which would seem to correspond to the above part of rename(2), i.e. perhaps EINVAL should be returned for RENAME and DELETE. --- Gary Jennejohn