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

From: "Linda A. Walsh" <[email-masked]>
Date: Thu, 18 Sep 2014 16:40:41 -0700

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.  :-|