Re: POSIX 2008 available, openat

[Jim Meyering]

Bruno Haible <address@hidden> 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.