[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/8] maint: fts.c: remove #if-0'd FTS_WHITEOUT code
From: |
Jim Meyering |
Subject: |
Re: [PATCH 1/8] maint: fts.c: remove #if-0'd FTS_WHITEOUT code |
Date: |
Thu, 18 Aug 2011 21:03:37 +0200 |
Eric Blake wrote:
> On 08/18/2011 07:53 AM, Jim Meyering wrote:
>> From: Jim Meyering<address@hidden>
>>
>> ---
>> 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
...
- fts: do not exhaust memory when processing million-entry directory, Jim Meyering, 2011/08/18
- [PATCH 3/8] maint: fts.c: correct off-by-one indentation, Jim Meyering, 2011/08/18
- [PATCH 2/8] maint: fts.c: move __opendir2 #define "up" out of function body, Jim Meyering, 2011/08/18
- [PATCH 7/8] fts: move decl of "dp" into while loop; split long line, Jim Meyering, 2011/08/18
- [PATCH 5/8] maint: fts: give __opendir2 a new parameter, Jim Meyering, 2011/08/18
- [PATCH 6/8] fts: add/use new struct member, fts_dirp, Jim Meyering, 2011/08/18
- [PATCH 8/8] fts: do not exhaust memory when processing million-entry directories, Jim Meyering, 2011/08/18