GNU bug report logs -
#18491
rm -r fails to delete entire hierarchy when path goes in and out of it
Previous Next
Full log
Message #14 received at 18491 <at> debbugs.gnu.org (full text, mbox):
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. :-|
This bug report was last modified 10 years and 278 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.