bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it

[Linda Walsh]

Alan Curry wrote:
> Eric Blake writes:

>         if (isdot(cp)) {
>                 fprintf(stderr, "rm: cannot remove `.' or `..'\n");
>                 return (0);
---
The thing is, by doing rm -rf on ., I am not trying to remove . or ..
I'm trying to remove the files in it.

Other wise there is no way to specify, using "rm" to delete the contents
of a directory  but not the directory itself.

I just want to "clean" out a directory -- I don't want to try to delete the
directory itself.  4.3BSD is breaking the intended functionality of
a depth first *requirement* for rm to remove a dir.  It's well known
that the contents must be removed before ".", so trying to remove "." should
only fail after the depth first traversal -- that would be expected behavior.
I'm NOT trying to remove "."   I'm using it to indicated that I only want the
contents of the directory deleted.   It's like using "/" with a symlink to get 
at
the dir, except that doesn't work reliably -- the only thing that works reliably
to get at the contents is "."

Try <cp|mv> -r dir1/ dir2/ -- they'll move dir1 under dir2, the same as without
the "-r".  The only way for "-r" to address content is by using "." as the 
source,
in
cp -a src/. dst[/]

Note cp -a src/. dst/. works, but try to "mv", and you get the type of error 
you'd
expect from trying to "destroy" "b/."

Note the copy works but not the mv.  cp should realize it is writing "." to "." 
which
is illegal -- but it allows it because it knows what the user *wants* to do.

'mv', is stricter -- as you want to move one inode over the top of another.

As a "source address, "." is allowed to mean content, but as a destination, it 
isn't
allowed as a writeable destination.

That's the problem with "rm", when uing rm -r '.' that specifies the start of a
recursive operation where writes will begin, depth first.  It's not until the
very end that it tries to do the illegal "write (delete)" operation to ".".

If 'cp' allows "." as a source, (and even accommodates it as a target for "cp",
so should 'rm' allow "." to mean the start of a deletion, but NOT the dir 
itself.

That's the interpretation that cp is using -- as if it was trying to cp the dir 
itself
over the top of the target, it would give an error message, but it doesn't.