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

[Jim Meyering]

address@hidden (Eric Blake) wrote:
>> 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.
...

It would be a shame if POSIX were to standardize a version of fts that
cannot be used in programs that are robust, efficient and thread-safe.
I certainly would not use it.

Of course, I thought long and hard before deciding to change the API,
and I admit it is certainly possible to support both the old and the
new ones, and it's not even that hard.  However, I'm not sure it's
worth the added complexity.  Part of the problem is that the classic
API is inherently buggy: it changes the current working directory.
Now that we have portable (albeit not thread-safe) emulation of the
openat-like functions, I find it hard to justify spending more time to
obfuscate further an already-complicated bit of code.

If rewriting client applications to use the new API requires
lots of effort, or if there turn out to be clients that are hard
to convert, I'll be more sympathetic to the cause.

FYI, I did most of the work to add FTS_CWDFD, just to see -- and it's
not so bad, but the result is certainly less maintainable.