openat status: new glibc emulation

[Jim Meyering]

A few days ago, Ulrich Drepper and I were talking, and I mentioned
the openat[*] problem (that Solaris has it, but Linux doesn't, and
that it'd be so nice to be able to use it in places like fts.c,
mkdir-p.c, remove.c, etc.).  Sure, we have replacement functions
in gnulib's lib/openat.c, and they work almost all of the time,
but not always.  Well, he found a way to implement it using /proc
file system support, and now it's in glibc.  No fchdir needed.
This means that an openat-based rm command can now work on Linux as
well as on Solaris, when run from an unreadable working directory.
So progressive glibc-based systems will soon provide openat et al.
Thanks, Uli!

FYI, the trick is to realize that openat (FD, filename, ...) is
the same as calling open ("/proc/self/fd/NNN/FILENAME", ...) --
when you have /proc support.

This is a great complement to the existing save_cwd/restore_cwd
technique, since it lets us avoid changing away from the current
directory most of the time -- the only drawback is that glibc's
openat emulation relies on procfs support.  If /proc is unavailable
or inaccessible, that emulation fails, so we still need to fall
back on using save_cwd and restore_cwd.

Note: with this new openat emulation in glibc, we'll have to
change gl_FUNC_OPENAT not to test solely for the presence of the
openat function, since the gnulib emulation has to supersede
the glibc one.

I've just change coreutils' lib/openat.c to do this:

2005-11-12  Jim Meyering  <address@hidden>

        Emulate openat-family functions using Linux's procfs, if possible.
        Idea and some code based on Ulrich Drepper's glibc changes.

        * openat.c: (BUILD_PROC_NAME): New macro.
        Include <stdio.h>, <string.h>, "alloca.h" and "intprops.h".
        (rpl_openat): Emulate by trying to open /proc/self/fd/%d/%s,
        before falling back on save_cwd and restore_cwd.
        (fdopendir, fstatat, unlinkat): Likewise.

These openat-family functions should be implemented in every kernel,
and I suppose eventually, they will be -- in the ones that matter.
In the mean time, the overhead of using their replacements is minimal,
and they work under almost all circumstances, even on systems without
procfs support.

[*] I've harped about this before.  E.g., here:
<http://lists.gnu.org/archive/html/bug-coreutils/2005-04/msg00124.html>
Plus, I've finally written to the linux-kernel list,
<http://www.ussg.iu.edu/hypermail/linux/kernel/0511.1/1648.html>
requesting that they consider adding support for openat et al.