On Sun, Feb 28, 2010 at 5:11 PM, Alexander Best <[email protected]> wrote: > i have a small test app to check {rm|mk}dir()'s errnos with certain args like > /, ., /proc and non-empty dirs. i'll submit it to this thread as soon as i > also add testcases for syscalls like rename(), unlink(), etc. > > most of the errno codes returned after applying your patch look correct. i > wonder however why rmdir("/proc") returns EACCESS as unprivileged user. > wouldn't it make more sense to also return EBUSY? why complain about > permission related matters when even root won't be able to perform the > operation.
Hmm.. good question. POSIX doesn't fully expound on this case (http://www.opengroup.org/onlinepubs/009695399/functions/rmdir.html), and either seem possible... > also: since namei() takes care of handling the "/" and "." cases couldn't > those checks in kern_rmdirat() and kern_unlinkat() be removed? > > it might also be interesting to look at the changes netbsd, openbsd and > dragonflybsd have made to vfs_lookup.c. just had a quick look at revision > 1.121 from netbsd and they have split lookup() into loads of smaller functions > (see revision 1.117 and 1.118). seems they have been doing a lot of work here > (using heavy XXX-commenting however). > > openbsd hasn't made to many changes to vfs_lookup.c. > > matthew dillon seems to have done an incredible job on dragonfly in connection > with vfs_lookup.c. basically they completely got rid of namei() and are now > using nlookup() in commit ad57d0edbfceb0cebfb1dce61490df78fcc4a97. the commit > message is quite long and claims due to this change all syscalls which used to > call namei() have become a lot less complex after switching to nlookup(). > > right now vfs_lookup.c in dragonfly contains only some legacy code used for > compatibility. > > again: an incredible job! > > +1 for adapting those changes. ;) > > cheers. > alex > > btw.: there're a few NAMEI_DIAGNOSTIC ifdefs in vfs_lookup.c to increase > verbosity. Thanks, -Garrett _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[email protected]"
