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: Daniel Jacobowitz <drow at false dot org>
- To: Jim Meyering <jim at meyering dot net>
- Cc: Roland McGrath <roland at redhat dot com>, 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 19:55:05 -0500
- Subject: Re: FYI: new openat-like function: mkdirat
- References: <20051130213658.F23021809B9@magilla.sf.frob.com> <87hd9tn4sf.fsf@rho.meyering.net>
On Wed, Nov 30, 2005 at 11:34:40PM +0100, Jim Meyering wrote:
> 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.
You're talking about exec. If you're going to use execve anyway,
there's no way you need your old initial working directory back, is
there?
--
Daniel Jacobowitz
CodeSourcery, LLC