This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: FYI: new openat-like function: mkdirat
- From: Jim Meyering <jim at meyering dot net>
- To: Roland McGrath <roland at redhat dot com>
- Cc: bug-gnulib at gnu dot org, libc-alpha at sources dot redhat dot com, Ulrich Drepper <drepper at redhat dot com>
- Date: Wed, 30 Nov 2005 23:34:40 +0100
- Subject: Re: FYI: new openat-like function: mkdirat
- References: <20051130213658.F23021809B9@magilla.sf.frob.com>
Roland McGrath <roland@redhat.com> wrote:
>> So I guess the exec*at business would ultimately be more complicated,
>> with two file descriptor parameters: one identifying the working
>> directory, and another by which to interpret the first parameter
>> if it's a relative file name.
>
> It seems adequate to just use chdir/fchdir for changing cwd, and then
> execveat given the file name (you can get an fd for the original cwd before
> chdir, for relative paths in exec).
Using chdir/fchdir is _usually_ adequate.
But what about the other times? Sometimes you *cannot*
get an fd (or an absolute name) for an initial cwd.
Changing cwd is problematic whenever:
- your code must be thread-safe
- it would be impossible to restore the initial working
directory, once it's been changed -- thereafter, no reference
to a `.'-relative name can be resolved.
With the openat-style functions (as implemented with Linux/proc or
in Solaris kernels), there is no need to change the initial working
directory at all.
> But note that we already have fexecve.
Thanks. I didn't know about that.