Bug 59739

Summary: [patch] [libc] rmdir(2) and mkdir(2) both return EISDIR for argument "/"
Product: Base System Reporter: Andreas Fuchs <asf>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Open ---    
Severity: Affects Only Me CC: bapt, ngie, zkliuchaojie
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   
Description Flags
vfssyscalls.c.patch.txt none

Description Andreas Fuchs 2003-11-27 21:20:13 UTC
	Calling rmdir or mkdir on "/" returns EISDIR, but calling them 
	on any other mount point name returns the documented and correct
	return value (EBUSY for rmdir and EEXIST for mkdir).

	This seems to affect only the literal value "/". Using 
	"/etc/.." (where "etc" is a regular directory, just to be sure) 
	yields the correct result.


I /think/ the problem lies somewhere in namei() (or lookup() from there)
	calls from rmdir and mkdir, but neither am I a kernel hacker nor could I 
	find the bug in there. This is all rather speculative, so I can't really 
	offer a fix - sorry.
How-To-Repeat: 	# rmdir /
	rmdir: /: Is a directory
	# rmdir /usr
	rmdir: /usr: Device busy
	# rmdir /etc/..
	rmdir: /etc/..: Device busy
	same for mkdir:
	# mkdir /
	mkdir: /: Is a directory
	# mkdir /usr
	mkdir: /usr: File exists
	# mkdir /etc/..
	mkdir: /etc/..: File exists
	(where /etc is not a mount point, so /etc/.. would be the root directory)
	I could repeat this on 5.2-BETA and 4.9-STABLE.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2005-10-24 19:02:22 UTC
State Changed
From-To: open->suspended

Mark as 'suspended' since this does not seem as though it is being 
actively worked on.
Comment 2 Joe Peterson 2007-08-02 22:01:12 UTC
Hi, we at Gentoo/FreeBSD just ran into this issue with a script that had
worked on Linux, since it expected EEXIST for all dirs (it did not
expect EISDIR when trying to mkdir an existing dir when it hit "/").  We
have fixed it, but since the mkdir/rmdir man pages do not specify EISDIR
as a potential error code - and just for correctness/compatibility
reasons - my feeling is that it would be good to fix this issue.  I also
have no experience hacking FreeBSD kernel or userland utilities, so I
have not pursued providing a patch.  Sorry if this follow-up is not
useful without having a patch.

						-Thanks, Joe
Comment 3 Alexander Best 2009-11-06 16:08:08 UTC
this problem still exists under 9-current.

the following test app:

#include <sys/stat.h>
#include <errno.h>
#include <stdio.h>
#include <unistd.h>

main() {
    printf("rmdir errno: %d\n", errno);
    mkdir("/", 511);
    printf("mkdir errno: %d\n", errno);

produces this output:

rmdir errno: 21
mkdir errno: 21

which is EISDIR (as reported by Andreas Fuchs).

could somebody please check if the attached patch is sufficient to solve this
problem? with the patch the test app now outputs:

rmdir errno: 16
mkdir errno: 17

16 being EBUSY and 17 being EEXIST. this is what Andreas Fuchs suggested.

Comment 4 Alexander Best 2009-11-06 16:49:41 UTC
the patch supplied in the previous followup is currently being discussed in
this thread:


a final patch will be supplied in the next few days as followup to this
problem report. thus please ignore the previous patch.

Comment 5 Mark Linimon freebsd_committer freebsd_triage 2009-11-06 18:14:42 UTC
State Changed
From-To: suspended->open

There is now an open thread dicussing the patch (see Audit-Trail).
Comment 6 Alexander Best 2009-11-08 03:05:11 UTC
after discussing this problem in the thread mentioned in the previous followup
it was decide to move all changes to sys/kern/vfs_syscalls.c in order not to
break any code which relies on namei() returning EISDIR.

attached you'll find the final patch (which supersedes the previous one). this
patch doesn't require any changes to the rename(2), mkdir(2) or rmdir(2)

please set this pr into analysed state.

Comment 7 Mark Linimon freebsd_committer freebsd_triage 2009-11-10 08:16:33 UTC
State Changed
From-To: open->analyzed

A patch has been circulated and an approach agreed on.
Comment 8 Alexander Best 2010-03-03 00:16:30 UTC
new discussion with new patch by jh@:

Comment 9 Alexander Best 2010-04-19 11:46:02 UTC
i think this issue got fixed in r205682. please mark patched and assign to jh@
as MFC reminder.

Alexander Best
Comment 10 Mark Linimon freebsd_committer freebsd_triage 2010-04-19 15:37:29 UTC
State Changed
From-To: analyzed->patched

Apparently jh committed a patch.  Assign and set to patched as MFC reminder. 

Comment 11 Mark Linimon freebsd_committer freebsd_triage 2010-04-19 15:37:29 UTC
Responsible Changed
From-To: freebsd-bugs->jh
Comment 12 Mark Linimon freebsd_committer freebsd_triage 2010-04-19 20:04:33 UTC
State Changed
From-To: patched->analyzed

false alarm, it seems. 

Comment 13 Mark Linimon freebsd_committer freebsd_triage 2010-04-19 20:04:33 UTC
Responsible Changed
From-To: jh->freebsd-bugs
Comment 14 Garrett Cooper 2011-10-15 00:54:52 UTC
This seems to have been regressed again:

$ mkdir /
mkdir: /: Is a directory
$ mkdir /var
mkdir: /var: File exists

Comment 15 Petr Salinger 2012-06-03 14:24:05 UTC

it still a valid problem, at least in 8.1 and 9.0 releases.

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675768

Comment 16 Eitan Adler freebsd_committer freebsd_triage 2012-07-01 17:11:01 UTC
State Changed
From-To: analyzed->open

this is still a bug
Comment 17 Enji Cooper freebsd_committer 2015-11-10 10:42:22 UTC
Still the case, I think:

$ uname -a
FreeBSD fbsd11 11.0-CURRENT FreeBSD 11.0-CURRENT #7 r289441+9ae1597(isilon-atf): Sat Oct 17 01:21:49 PDT 2015     ngie@fbsd11:/usr/obj/usr/src/git/sys/GENERIC-NODEBUG  amd64
$ sudo rmdir /
rmdir: /: Is a directory
$ sudo mkdir /
mkdir: /: Is a directory

bapt might have a patch in the wings for fixing this.
Comment 18 Baptiste Daroussin freebsd_committer 2015-11-10 10:46:07 UTC
I'm sorry but I have nothing in the wings :(
Comment 19 Eitan Adler freebsd_committer freebsd_triage 2018-05-20 23:53:17 UTC
For bugs matching the following conditions:
- Status == In Progress
- Assignee == "bugs@FreeBSD.org"
- Last Modified Year <= 2017

- Set Status to "Open"