Bruno Haible <br...@clisp.org> wrote: >> openat emulation depends on save-cwd (GPL), which can call xgetcwd (GPL), >> which >> in turn can call xalloc_die (GPL)? > > openat() and the related system calls are not supposed to signal errors by > themselves and exit the program. Is it possible to restructure the code so > that > they only return an error code?
Without a solution to the show-stopper (failing-restore_cwd) problem, see below, it's hard to justify most of these changes. > The dependency openat -> save-cwd -> xgetcwd -> xalloc-die (GPL) could IMO be > avoided by having save_cwd() either return or save an error code of ENOMEM in > case of failure. > > The dependency openat -> dirname could be avoided by merging the 'filename' > and 'dirname' modules, something with is already on my TODO list for a long > time. > > The dependency openat -> lchown could be handled by changing the license of > 'lchown' to LGPL, if you agree. > > The dependency openat -> rmdir could be dropped; the module 'rmdir' is > obsolete. > > However, for openat-die.c I don't see a good replacement. In particular, I > don't see a way how openat_restore_fail() could be handled in library code. > A program cannot simply continue when its current directory is different from > what it was expecting. And errno values don't adequately capture this > situation. ?? Any ideas? That is why I resist change on this front: I don't see an acceptable solution. Users expect tools like chmod -R, du and find to work even when run from an unreadable directory. Once you impose that requirement, you have admitted that save_cwd and restore_cwd are required. With them you must admit the possibility of restore_cwd failure. And openat's interface does not allow for that, since it must not change the working directory. Since I require that coreutils applications use the *at-function interfaces, I'm stuck with the possibility, however remote, that a normally library-quality *at-function may exit. Bear in mind that the possibility *is* relatively remote in practice. How often do you run directory-traversing commands from within an unreadable directory whose absolute name is longer than PATH_MAX? Besides, once you admit the possibility of using chdir (required as long as openat lacks O_SEARCH support), you've sacrificed thread-safety. Once we get the kernel open/O_SEARCH support now promised by POSIX.2008, we'll finally be able to eliminate this source of race-condition bugs.
