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

[Linda Walsh]

Jim Meyering wrote:
> I see from your mention of "." below that you are objecting
> to rm's refusal to remove "." or "..".
---
        I see from your response that you misunderstood
what I wrote.   There was no mention of "..".  I wouldn't expect
"rm" to crawl backward out of a "rm" in any even -- error message or
not.

> POSIX requires rm to reject any attempt to delete an explicitly specified
> "." or ".." argument (or any argument whose last component is one of those):
>
>     http://pubs.opengroup.org/onlinepubs/000095399/utilities/rm.html
---
        


        But you fail to follow the earlier stated POSIX
requirement:

..
" If this fails for any reason, rm shall write a diagnostic message to standard 
error, do nothing more with the current file, and go on to any remaining files."
Specifically, in regards to a failure to remove a directory:

For each entry contained in file, other than dot or dot-dot, the four steps 
listed here (1 to 4) shall be taken with the entry as if it were a file operand. 
The rm utility shall not traverse directories by following symbolic links into 
other parts of the hierarchy, but shall remove the links themselves."




So for each entry in ".", except for . and .., rm is to traverse and remove them
even after encountering an error -- which normally, it would only encounter at 
the
end of removing all files in the directory.


> > Sides -- it normally does depth-first traversal --- since you can't delete
> > a dir with contents still in it -- so why different for '.'?
>
> Safety, I suspect.  "." and ".." may not mean anything to a novice.

----
Again, ".." isn't the issue anymore than it should be skipped.

What is at issue is the order of deletion (depth first), and
it's not continuing to delete the other entires in the 'file' other
than "." and ".." after encountering any errors (including a rejection
to delete . and ..).


So the error message is fine.

But not deleting everything else in the dir isn't (at least
judging from the POSIX doc you pointed me at... -- Thanks for
the reference!