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

[Linda Walsh]

Eric Blake wrote:
> On 09/07/2012 08:54 AM, Linda Walsh wrote:
> > Using "." to reference content of a dir is standard in other utils -- that
> > it doesn't work in 'rm' goes counter to the idea of how rm works -- you
> > have
> > to remove contents before trying the current dir.  It isn't logical to
> > think
> > that it would try the current dir before anything else -- as it goes
> > completely
> > contrary to how rm has to work.
>
> At the syscall level, unlink(".") is required to fail.  To remove a
> directory, you must remove its proper name.  You can use
> unlink("../child") on systems like Linux that let you remove a directory
> that is used as a process' current working directory (on systems like
> Windows where this action is forbidden, there's no way to remove the
> current working directory).  Therefore, at the shell level, POSIX will
> let you do 'rm -r ../child'.  If you think that POSIX should _also_ let
> you attempt 'rm -r .', then propose that as a defect report against
> POSIX, rather than griping here.
>
> > I say it's a design flaw and inconsistent with other programs.
>
> I would say that it is not a design flaw, but that it is consistent with
> the fact that the unlink(".") syscall is required to fail, and that it
> is consistent with other Unix implementations.  We can agree to disagree
> on that point.

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.

It's the special check BEFORE doing the work it would normally do, and failing
BEFORE, it does it's NORMAL work -- the depth first deletion, that I am against.

Griping against POSIX is like griping against the government. But very
few people always go the speed limit and would regard a vehicle that is
*unable* function normally, as faulty.

So I am not disagreeing that it should fail, Please be clear about what I
am asking.   Also, I would *expect*, that rm -r . would at least,  _ask_ you
if you wanted to remove files under a directory that will be unable to be 
deleted.

I am only asking for the behavior I describe to work without issuing an error
when I do "rm -fr"  I am specifically asking rm to forcefully remove what it
can and remove and CONTINUE to delete what it can in spite of any errors it 
might
encounter.   Again, the fact that this fails defies normal logic with 'rm'.  I 
don't
believe that rm -fr . has failed for 20 years.  I don't know when it changed, 
but it used
to be that "rm" didn't have a special check for "." -- BECAUSE -- as you 
mention, an attempt
to unlink "." will fail -- Using the "-f" suppresses any error message.