rm shouldn't require /proc to be mounted

This is reroducible with the simple test case below:

root@ross:/tmp# mkdir -p foo/bar/baz
root@ross:/tmp# touch foo/bar/baz/ungh
root@ross:/tmp# rm -rf foo/
rm: cannot remove `foo/bar': Function not implemented

Hi,

I'm just dumping a few notes in to the bug so that
I don't lose them.

Firstly, the linked Debian bug has some good
analysis of the problem.

I found a couple of possibly related links:

http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/6839
http://<email address hidden>/msg07872.html

James

Confirmed again by me, test case reproducible as above.

upstream has this commented at http://lists.gnu.org/archive/html/bug-coreutils/2008-08/msg00149.html. It can be summarised as:

"naruto canada" <address@hidden> wrote:
> On 8/19/08, Jim Meyering <address@hidden> wrote:
>> "naruto canada" <address@hidden> wrote:
>>> Starting from coreutils-6.3.tar.bz2 upward, when compiled against
>>> glibc-2.5.1,
>>> "rm" requires /proc mounted else this error "cannot remove `...':
>>> Function not implemented" is triggered.
>>
>> I reworked remove.c to use the then-new *at functions (openat, statat,
>> etc.) and when those kernel functions are not available, the code
>> falls back on using /proc-based emulation, when possible.
>> There's a still older approach (lib/save-cwd.c), which is what
>> earlier versions of coreutils use.
>>
>> If you're stuck using glibc-2.5.x, can you stick with
>> the older version of coreutils, too?
>
> That's what I did.
>
> How about newer glibc-- 2.6 upwards? I've not tried them yet.

With a new enough kernel (including openat et al syscalls),
it should work with any glibc version that provides the
wrappers and declarations. I don't remember off hand which
was the first.

I don't think we are going to do anything about this now unfortunately.

Almost all supported releases now have new enough kernels, so there is
little incentive for future development, and the cost is quite high.

Thanks,

James