Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: >>> I initially tried something like that, but got too confused by it, >>> perhaps partly because I wanted to fall back on something like the >>> current approach when mkdirat didn't work (which is a common case >>> these days, even on GNU/Linux systems, alas). >> >> What do you mean? >> Of course, for at-function-syscall support, you need Linux 2.6.16 or >> newer, but gnulib's mkdirat emulation works well also with /proc/self/fd/N >> support, which is available back at least to linux-2.4.x. >> Admittedly, /proc isn't always available, but I wouldn't say that's "common". > > I was thinking of the "/proc isn't available" case. > You're right, it's not that common, but we do > get bug reports....
I do recall one bug report that ended up being due to a misconfigured system: /proc was unreadable. And of course, even with a kernel that supports /proc, you can create a chroot environment that lacks /proc altogether. But even there, the save-cwd-based emulation works fine except in the very unusual case where the working directory cannot be saved or restored. Then, consider the rare cases in which it fails, but would otherwise be able to do useful work, and you realize that it just doesn't matter. Those cases are just too contrived: working directory too deep (longer than PATH_MAX) for getcwd to work, or recursing into some subtree and then trying to create something in a writable, but unreadable initial working directory. Some would say we have to be over the edge to think up such extreme scenarios. As far as I recall, there have been *no* reports of gnulib's at-function _emulation_ layer failing. For me, the important thing is to use the "right" (clean, modern, standard[*]) APIs. In my book, that means using openat, mkdirat, etc. to solve this sort of problem, not the thread-unsafe chdir. [*] in that order :-) We should be coding for the future. If all systems will eventually end up providing openat support (IMHO, they will), then we should feel free to use it now, as long as the emulation layer is "good enough". Just as we don't mind imposing some overhead or small additional risk on old and deficient systems through wrapper functions, we can and should do the same when it comes to slightly more modern systems that lack features we think are important enough. > I was also worried a bit about bugs in /proc itself, which are more > likely to be tickled by these usages. For example: > > mkdir -p /proc/self/fd/0/../tmp/foo </ > > where if we use /proc/self/fd internally, then we're in effect using > /proc/self/fd once on itself. It _should_ work, even when the file > name crosses mount points, but _does_ it? (I'm almost afraid to try. > :-) That's truly twisted :-) But we shouldn't let the *possibility* of a bug affecting an emulation layer (*if* there is such a bug, it'll matter only on old systems) determine whether to use a superior API. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
