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 <[EMAIL PROTECTED]> 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. _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib