On Feb 20, 2008 12:12 PM, Jim Meyering <[EMAIL PROTECTED]> wrote: > This reminds me of the long-planned fork, e.g., s/fts_*/gfts_*/, > (all public symbols) in which I create new files named gfts.[ch]. Then, > someday, I can propose adding it to glibc. Remember, proposing the > addition with new names is the only way to add the improved functions > to glibc, due to the API changes that make the gnulib version more robust.
I'm looking forward to collaborating on that. > A couple months ago I finally did most of the work, and have adapted > coreutils to use the new names (still all private for the moment). > Just need to find time to write ChangeLog entries, etc. and decide how > to handle maintenance of the resulting duplication. I'm leaning toward > deriving gfts.c mechanically, at least initially, but that's messy. > There are many exceptions, and evaluating that takes time, too. I should point out that Martin has been finding that the fts-based find exhibits different behaviour to the non-fts find on file systems with a Sun Solaris automounter. We don't yet have details of what, in particular, is different about what the fts based version is doing. However, he noted that --disable-leaf-optimisation doesn't have any effect on the fts-based find executable. Details (and a patch which appears actually to not solve the problem, somewhat to my surprise) at http://savannah.gnu.org/bugs/?22301. Thanks, James.
