Re: making fts thread-safe (no more fchdir)

[Eric Blake]

> 
> FTS API change:
> ==============
> 
> This changes the fts API.  Before, callers (those not using FTS_NOCHDIR)
> could expect fts_read to change the current working directory so that
> a simple directory entry name (fts_accpath) could be used to access
> files in the directory in question.  Now, the current working directory
> is never changed, and instead, each caller must use an openat-like
> function to access that same name.  The only difference is that they
> must also use the new member, fts_cwd_fd, which is a file descriptor
> open on the virtual current working directory.

I'm a little uncomfortable with this, since fts might be accepted into
a future version of POSIX.  It is not a good idea for us to break API
with the semantics used by native versions.  Can we instead write
a wrapper fts_openat() which guarantees that the fts_accpath entry
name is relative to fts->fts_cwd_fd, but that normal uses of fts_open()
continue to return entries with fts_accpath relative to the current
working directory?  One other benefit of such a name change would
be that it is a little more obvious in the code that fts_openat() implies
reentrency and using chmodat(), where fts() implies changing
directories and using chmod().  Or maybe we could add a new
FTS_CWDFD option to regular old fts_open(), so that an application
has to explicitly request the new and improved reentrant fts behavior,
rather than breaking when upgrading from a native fts to gnulib.

--
Eric Blake