Date: Fri, 06 Nov 2009 22:09:49 +0100 (CET) From: Alexander Best <alexbestms@math.uni-muenster.de> To: <gary.jennejohn@freenet.de>, Alexander Best <alexbestms@math.uni-muenster.de> Cc: freebsd-hackers@FreeBSD.org Subject: Re: rmdir(2) and mkdir(2) both return EISDIR for argument "/" Message-ID: <permail-20091106210949f0889e8400000862-a_best01@message-id.uni-muenster.de> In-Reply-To: <20091106182308.14dffc50@ernst.jennejohn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a MIME encoded multipart message. --+permail-20091106210949f0889e8400000862-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gary Jennejohn schrieb am 2009-11-06: > On Fri, 06 Nov 2009 17:43:06 +0100 (CET) > Alexander Best <alexbestms@math.uni-muenster.de> wrote: > > Gary Jennejohn schrieb am 2009-11-06: > > > On Fri, 06 Nov 2009 16:32:22 +0100 (CET) > > > Alexander Best <alexbestms@math.uni-muenster.de> 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 here's a completely new patch. all the changes are in kern/vfs_syscall.c. so kern/vfs_lookup.c now stays just the way it is (please revert any changes from the previous patches i posted). after applying the patch this is the output from a slightly modified version of the test app i attached in my very first post: rmdir errno: 16 (EBUSY) <- EBUSY is required by POSIX mkdir errno: 17 (EEXIST) rename errno: 22 (EINVAL) these are the results when called with "/" as arg. the output doesn't differ if run with or without superuser privileges. when run with "." as arg this is the output as regular user: rmdir errno: 22 (EINVAL) mkdir errno: 17 (EEXIST) rename errno: 13 (EACCES) and as superuser: rmdir errno: 22 (EINVAL) mkdir errno: 17 (EEXIST) rename errno: 22 (EINVAL) does this look reasonable? would be nice if mkdir and rmdir would also check privileges at first like rename, but that's a different story i guess. ;) alex --+permail-20091106210949f0889e8400000862-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="vfssyscalls.c.patch.txt" LS0tIHZmc19zeXNjYWxscy5jCTIwMDktMTEtMDYgMjI6MDc6MDguMDAwMDAwMDAwICswMTAwCisr KyAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3lzY2FsbHMuYwkyMDA5LTExLTA2IDIxOjM3OjQ3LjAw MDAwMDAwMCArMDEwMApAQCAtMzUsNyArMzUsNyBAQAogICovCiAKICNpbmNsdWRlIDxzeXMvY2Rl ZnMuaD4KLV9fRkJTRElEKCIkRnJlZUJTRCQiKTsKK19fRkJTRElEKCIkRnJlZUJTRDogaGVhZC9z eXMva2Vybi92ZnNfc3lzY2FsbHMuYyAxOTY4ODcgMjAwOS0wOS0wNiAxMTo0NDo0Nloga2liICQi KTsKIAogI2luY2x1ZGUgIm9wdF9jb21wYXQuaCIKICNpbmNsdWRlICJvcHRfa2R0cmFjZS5oIgpA QCAtMzU4Nyw4ICszNTg3LDEyIEBACiAJICAgIEFVRElUVk5PREUxLCBwYXRoc2VnLCBvbGQsIG9s ZGZkLCB0ZCk7CiAjZW5kaWYKIAotCWlmICgoZXJyb3IgPSBuYW1laSgmZnJvbW5kKSkgIT0gMCkK KwlpZiAoKGVycm9yID0gbmFtZWkoJmZyb21uZCkpICE9IDApIHsKKwkJLyogVHJhbnNsYXRlIGVy cm9yIGNvZGUgZm9yIHJlbmFtZSgiLyIsICJkaXIyIikuICovCisJCWlmIChlcnJvciA9PSBFSVNE SVIpCisJCQllcnJvciA9IEVJTlZBTDsKIAkJcmV0dXJuIChlcnJvcik7CisJfQogCWZ2ZnNsb2Nr ZWQgPSBOREhBU0dJQU5UKCZmcm9tbmQpOwogCXR2ZnNsb2NrZWQgPSAwOwogI2lmZGVmIE1BQwpA QCAtMzczNyw4ICszNzQxLDEyIEBACiAJTkRJTklUX0FUKCZuZCwgQ1JFQVRFLCBMT0NLUEFSRU5U IHwgU0FWRU5BTUUgfCBNUFNBRkUgfCBBVURJVFZOT0RFMSwKIAkgICAgc2VnZmxnLCBwYXRoLCBm ZCwgdGQpOwogCW5kLm5pX2NuZC5jbl9mbGFncyB8PSBXSUxMQkVESVI7Ci0JaWYgKChlcnJvciA9 IG5hbWVpKCZuZCkpICE9IDApCisJaWYgKChlcnJvciA9IG5hbWVpKCZuZCkpICE9IDApIHsKKwkJ LyogVHJhbnNsYXRlIGVycm9yIGNvZGUgZm9yIG1rZGlyKCIvIikuICovCisJCWlmIChlcnJvciA9 PSBFSVNESVIpCisJCQllcnJvciA9IEVFWElTVDsKIAkJcmV0dXJuIChlcnJvcik7CisJfQogCXZm c2xvY2tlZCA9IE5ESEFTR0lBTlQoJm5kKTsKIAl2cCA9IG5kLm5pX3ZwOwogCWlmICh2cCAhPSBO VUxMKSB7CkBAIC0zODI1LDEwICszODMzLDE1IEBACiAJYndpbGx3cml0ZSgpOwogCU5ESU5JVF9B VCgmbmQsIERFTEVURSwgTE9DS1BBUkVOVCB8IExPQ0tMRUFGIHwgTVBTQUZFIHwgQVVESVRWTk9E RTEsCiAJICAgIHBhdGhzZWcsIHBhdGgsIGZkLCB0ZCk7Ci0JaWYgKChlcnJvciA9IG5hbWVpKCZu ZCkpICE9IDApCisJaWYgKChlcnJvciA9IG5hbWVpKCZuZCkpICE9IDApIHsKKwkJLyogVHJhbnNs YXRlIGVycm9yIGNvZGUgZm9yIHJtZGlyKCIvIikuICovCisJCWlmIChlcnJvciA9PSBFSVNESVIp CisJCQllcnJvciA9IEVCVVNZOwogCQlyZXR1cm4gKGVycm9yKTsKKwl9CiAJdmZzbG9ja2VkID0g TkRIQVNHSUFOVCgmbmQpOwogCXZwID0gbmQubmlfdnA7CisJLyogWFhYIG5hbWVpKCkgdGFrZXMg Y2FyZSBvZiB0aGlzIGNhc2UuICovCiAJaWYgKHZwLT52X3R5cGUgIT0gVkRJUikgewogCQllcnJv ciA9IEVOT1RESVI7CiAJCWdvdG8gb3V0OwpAQCAtMzg0MSw2ICszODU0LDcgQEAKIAkJZ290byBv dXQ7CiAJfQogCS8qCisJICogWFhYIG5hbWVpKCkgdGFrZXMgY2FyZSBvZiB0aGlzIGNhc2UuCiAJ ICogVGhlIHJvb3Qgb2YgYSBtb3VudGVkIGZpbGVzeXN0ZW0gY2Fubm90IGJlIGRlbGV0ZWQuCiAJ ICovCiAJaWYgKHZwLT52X3ZmbGFnICYgVlZfUk9PVCkgewo= --+permail-20091106210949f0889e8400000862-a_best01+--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?permail-20091106210949f0889e8400000862-a_best01>