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
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
