> > 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