Subject: bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.

From: Eric Blake <[email-masked]>
Date: Fri, 07 Sep 2012 15:20:18 -0600

On 09/07/2012 02:56 PM, Linda Walsh wrote:

> Really, I didn't say rm -fr . should *delete* the current directory --
> IT SHOULD
> FAIL -- you are 100% correct.
> 
> But it is true that anyone who knows the smallest bit about unix knows
> that you have to empty the directory before deleting the directory, and,
> thus, "rm" _MUST_ do a depth first traversal.  If it did and gave an error
> at the end: no issue.

Indeed, reading the original V7 source code from 1979:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/rm.c

	while(--argc > 0) {
		if(!strcmp(*++argv, "..")) {
			fprintf(stderr, "rm: cannot remove `..'\n");
			continue;
		}
		rm(*argv, fflg, rflg, iflg, 0);
	}

shows that _only_ ".." was special, "." was attempted in-place and
didn't fail until the unlink(".") after the directory itself had been
emptied.  It wasn't until later versions of code that "." also became
special.

You therefore may have a valid point that POSIX standardized something
that did not match existing practice at the time, and therefore, it
would be reasonable to propose a POSIX defect that requires early
failure on "..", but changes the behavior on "." and "/" to only permit,
but not require, early failure.  However, I just checked, and the
prohibition for an early exit on "." has been around since at least
POSIX 2001, so you are now coming into the game at least 11 years late.

So, until you take it up with the POSIX folks, I don't think anyone on
the coreutils side cares enough to bother changing the default behavior,
now that it has been standardized, and even though the standardized
behavior is tighter than the original pre-standard behavior.

> Griping against POSIX is like griping against the government.

No, I actually find the Austin Group quite reasonable to work with,
especially if you can provide backup evidence like the V7 source snippet
I just mentioned.

-- 
Eric Blake   [email-masked]    +1-919-301-3266
Libvirt virtualization library http://libvirt.org