Re: [RFC] st_nlink after rmdir() and rename()

[Al Viro <viro@ZenIV.linux.org.uk>]

On Thu, Mar 03, 2011 at 09:34:08AM -0500, Theodore Tso wrote:
> 
> On Mar 2, 2011, at 10:24 PM, Al Viro wrote:
> 
> > We have an interesting problem.  Consider the following sequence
> > of syscalls:
> > 	mkdir("foo", 0777);
> > 	mkdir("bar", 0777);
> > 	fd1 = open("foo", O_DIRECTORY);
> > 	fd2 = open("bar", O_DIRECTORY);
> > 	rename("foo", "bar");	/* kill old bar */
> 
> I must be missing something.  I didn't think you could rename on
> top of a directory and have the directory disappear.  Don't you get
> an error in that case?  What happens if bar contains files?

ENOTEMPTY.  Checked by ->rename() and yes, ext4 does that.

> We don't allow:  mkdir("bar", 0777); unlink("bar");
> 
> Why should this be any different?

Because it worked since 4.2BSD and got into POSIX.  Replacing rename()
works; the only restrictions are
	* you can't replace directory with non-directory
	* you can't replace non-directory with directory
	* directory being replaced shall be empty
	* you can't replace a mountpoint or filesystem root
If the target is not busy, it is required to work.  Whether it returns
-EBUSY for busy target is implementation-dependent and we allow that
for most of the filesystems.