Eric Blake wrote: > On 08/18/2011 07:53 AM, Jim Meyering wrote: >> From: Jim Meyering<meyer...@redhat.com> >> >> --- >> lib/fts.c | 21 +-------------------- >> 1 files changed, 1 insertions(+), 20 deletions(-) >> >> diff --git a/lib/fts.c b/lib/fts.c >> index 7210c1b..c96dd9d 100644 >> --- a/lib/fts.c >> +++ b/lib/fts.c >> @@ -1233,12 +1233,6 @@ fts_build (register FTS *sp, int type) >> * Open the directory for reading. If this fails, we're done. >> * If being called from fts_read, set the fts_info field. >> */ >> -#if defined FTS_WHITEOUT&& 0 >> - if (ISSET(FTS_WHITEOUT)) >> - oflag = DTF_NODUP|DTF_REWIND; >> - else >> - oflag = DTF_HIDEW|DTF_NODUP|DTF_REWIND;
Thanks for the feedback. > __opendir2 is really a useful entry point on BSD systems, which are > the only ones where whiteout files are supported. Is our whiteout > support so bit-rotted that it really is time to remove it? You've just highlighted why that code is not worth preserving: it's BSD-specific. That code has been #if-0'd for years and no one has complained, and no gnulib client I know of uses FTS_WHITEOUT (they would have complained), so I think it's fine to remove it. The only reason I didn't remove it earlier was that I held out hope of syncing with some other version of fts.c. >> -#else >> # define __opendir2(file, flag) \ >> opendirat((! ISSET(FTS_NOCHDIR)&& ISSET(FTS_CWDFD) \ >> ? sp->fts_cwd_fd : AT_FDCWD), \ >> @@ -1249,7 +1243,7 @@ fts_build (register FTS *sp, int type) >> ? O_NOFOLLOW : 0) \ >> | (ISSET (FTS_NOATIME) ? O_NOATIME : 0)), \ >> &dir_fd) >> -#endif > > Once you make this definition of __opendir2 unconditional, even for > BSD, I'd rather rename it to something more appropriate (lose the > leading __, and maybe even go with a more descriptive name like > fts_opendir), so that we aren't risking a conflict with the BSD > function. Thanks. I nearly did that, but lazily kept the change minimal. I'll merge in the renaming to fts_opendir. > Besides, there's talk (although nothing definitive yet) about making > the next version of POSIX making it harder to create files with > literal newlines. The idea is that since file names with literal > newlines are dangerous, so the proposal is to modify the requirements > on a compliant libc to make it impossible to create new files with a I will refrain from comment. > literal newline but still possible to access existing files that were > created before the upgrade to the new POSIX. And since there are > differing use cases between traversing a directory where all names are > returned literally vs. where it is an error to try to traverse a ...