bug#18491: rm -r fails to delete entire hierarchy when path goes in and out of it

[Linda A. Walsh]

Bob Proulx wrote:
> Gian Ntzik wrote:
> > It seems that using rm -r with a path that goes into a (non-empty)
> > directory intended for removal (and back up e.g. using dot-dots) fails
> > to remove the directory. The directory is rendered empty, but itself not
> > removed.
> >
> > For example,
> >
> > $ mkdir -p /tmp/a/b/c
> > $ mkdir -p /tmp/a/e
> > $ rm -r /tmp/a/b/../../a
> > rm: cannot remove ‘/tmp/a/b/../../a’: No such file or directory
>
> I don't think this can reasonably be called a bug.  A depth first
> removal is required. 
----
   I would tend to agree, but if you try to remove /tmp/a/.
a "depth first removal" won't be tried -- so it is obviously not required.

> Trying to do anything to work around this seems wrong to me since it
> will require keeping track of the state before and simulating to
> create the desired state afterward and then applying a derived state
> change to the file system.  That is much too complex for this simple
> operation.
----
   One would think the same for rm -fr "foo/.", but the
straight-forward application of the depth-first removal was
removed from "rm" for special cases.  One would think
that the underlying tree might be easily addressed:

function rmr {
 local rd=$(cd "$1"; /bin/pwd)
 echo rm -r "$rd"
}

same dir struct as above:
>  tree /tmp/a
/tmp/a
├── b
│   └── c
└── e

>  rmr /tmp/a
rm -r /tmp/a

---
If rm should delete  the directory and its contents as it is documented
to do except where POSIX prohibits it, (like  "rm -fr dir/."),
then except for POSIX instructions to the contrary, it seems it
should make at least as trivial an effort as the above.  :-|