Re: openat, failing fchdir

[Eric Blake]

On 12/23/2010 05:08 AM, Bruno Haible wrote:
> Bastien ROUCARIES wrote:
>> If chdir is a problem, why not using a heavy weight approach (better safe
>> than sorry particularly if gnulib is used for a lot of project):
>> - fork and exec an helper for name resolution
>> - pass fd using a socket
>>
>> It is really heavy but it is on the safe side
> 
> I like your idea. It would be a safe way to implement openat().
> 
> How does "pass fd using a socket" actually work? There are apparently two
> ways to do it [1]:
>   - On Unix domain sockets, using sendmsg SCM_RIGHTS [2][3].
>     Likely portable to glibc, MacOS X, FreeBSD, NetBSD, OpenBSD, AIX, HP-UX,
>     IRIX, OSF/1, Solaris, Cygwin, Haiku. But not to Interix, mingw, BeOS.

Unfortunately, it is not possible to pass fds on cygwin; it is not
possible to implement SCM_RIGHTS on top of what Windows provides.  Then
again, cygwin's *at functions don't need replacing, so it's a moot
point.  The whole exercise here is how to cater to systems that don't
support native *at correctly.

> And on mingw, REPLACE_FCHDIR is 1, which means we assume that we use the
> emulated fchdir, which associates a file name to every file descriptor
> that maps to a directory. In this case, we could implement openat through
> filename concatenation.

Indeed; furthermore, mingw has the (in this case, nice) property that
absolute pathnames cannot be larger than about 256 bytes, so there's not
as much risk of the O(n^2) behavior that filename concatenation would
have on other systems with unlimited directory depth.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature