On 2014-09-17 12:52, Cathey, Jim wrote:
Pretty sure 'our' upstream rm (in a prior life) expressly
prohibited -r on starting paths that contained .. members.
Too many weirdo cases where you would get into trouble.
GNU rm opens the top-level directory and uses unlinkat(), fstatat(), etc. to
remove
files and subdirectories without having to resolve the paths for every
file/directory processed; so it runs into the problem (that some ".." link no
longer exists) only when it finally reaches that top-level directory.
It still refuses to operate on paths that _end_ in "/.." (or "/.").
I wonder if there's a reason it doesn't go one step further--get dirname()
of the top-level path, open _that_, and then use openat() on the _basename_--
to avoid having to re-resolve the path even when finally removing the top-level
dir.
It's not obvious to me at a glance; there's a quite lot of code in there.
--
"'tis an ill wind that blows no minds."
-----Original Message-----
From: busybox [mailto:[email protected]] On Behalf Of Ralf Friedl
Sent: Wednesday, September 17, 2014 2:02 AM
To: Gian Ntzik; [email protected]
Subject: Re: rm -r fails to delete entire hierarchy when path goes in and out
of it
Gian Ntzik wrote:
It seems that using rm -r with a path that goes into the hierarchy
intended for removal (and back up e.g. using dot-dots) fails to remove
the entire hierarchy.
For example,
$ mkdir -p /tmp/a/b/c
$ mkdir -p /tmp/a/e
$ rm -r /tmp/a/b/../../a
rm: can't remove 'a/b/../../a/e': No such file or directory
rm: can't remove 'a/b/../../a': No such file or directory
GNU rm does this:
$ mkdir -p /tmp/a/b/c /tmp/a/e
$ rm -r /tmp/a/b/../../a
rm: cannot remove '/tmp/a/b/../../a': No such file or directory
In general I think it is not a good idea to pass such arguments to rm.
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
