[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Linda A. Walsh
Subject: bug#18491: rm -r fails to delete entire hierarchy when path goes in and out of it
Date: Thu, 18 Sep 2014 16:40:41 -0700
User-agent: Thunderbird

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]