Bruno Haible wrote: >> Before embarking on changes to (or duplication of) infrastructure like >> the *at functions, please tell us about your motivation. Why do you care >> about whether openat may abort under unusual circumstances > > The reason is so that libposix can offer openat() and getcwd() among the > functions that it offers. > > Nothing in libposix should call chdir() without the guaranteed ability to > restore the previous working directory. And nothing in libposix should call > error(), since error reporting is the application's task. > > See <http://lists.gnu.org/archive/html/bug-gnulib/2010-12/msg00178.html> > and <http://lists.gnu.org/archive/html/bug-gnulib/2010-12/msg00069.html>. > > My proposal to solve the problem in December was naïve. I find it good that > Bastien thinks at a better one. > >> As I tried to explain, there does not seem to be a clean way >> to solve the problem > > I believe the stuff with chdir() is only needed in order to handle special > cases like > - long directory and file names that would otherwise lead to ENAMETOOLONG, > - access relative to a directory where 'cd $(pwd)' would not work, because > of missing permissions in the parent directories. > > Therefore I believe it should be possible to propose an openat() > implementation > in libposix that, admittedly, cannot handle these special cases. But that > would > be better than nothing. And coreutils, which does not want these restrictions, > would continue to use the current code for openat().
Hi Bruno, Sure, it's possible. So far, it's not clear that it is desirable. The question is whether it's worth adding the code to gnulib when the solution would require orders of magnitude more time and space. (that's just a guess. I haven't measured or even done back-of-envelope stat vs. statat-using-fork calculations) For example, I don't want to add anything to fts.c whose sole purpose is to accommodate POSIX-challenged systems. You may recall that at one point I removed all chdir-related support from fts.c, but ended up putting it back in... for now. >> the target systems that would benefit >> from this portability improvement are mostly old and dying: not supporting >> POSIX-mandated *at functions is a good sign that they are not evolving. > > Huh? Here's the portability state of openat(): > > $ ./show-portability openat > libc aix-7.1.0 > libc cygwin-1.7 > libcygwin cygwin-1.7 > libc solaris-2.10 > libc solaris-2.11_2010_11 > libc solaris-2.9 > MISSING in aix-4.3.2 aix-5.1.0 aix-5.2.0 aix-5.3.0a aix-6.1.0 beos > cygwin-1.5 freebsd-5.2.1 freebsd-6.0 freebsd-6.4 glibc-2.3.6 > hpux-10.20 hpux-11.00 hpux-11.11 hpux-11.23 hpux-11.31 interix-3.5 > irix-5.3 irix-6.5 macosx-10.3 macosx-10.4 macosx-10.5 mingw netbsd-3.0 > netbsd-5.0.1 netbsd-5.0 nsk-G06 openbsd-3.8 osf1-4.0d osf1-5.1a pips > solaris-2.4 solaris-2.5.1 solaris-2.6 solaris-2.7 solaris-2.8 > > Also, FreeBSD >= 8.0 has it. But OpenBSD and NetBSD do not have it. [1][2] > > I wouldn't say that MacOS X, OpenBSD, and NetBSD are "not evolving". Perhaps "not evolving" was too strong. "ill-adapted to writing robust dir-traversal code" is more accurate. In failing to provide those POSIX-specified interfaces, they are certainly not keeping up, and imho, not evolving in the right direction. Personally, I find it harder and harder to justify working around portability problems on those systems, especially when the work-around code makes it harder to maintain code that targets more progressive systems.
