Re: [PATCH 1/8] maint: fts.c: remove #if-0'd FTS_WHITEOUT code

[Eric Blake]

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;

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

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

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 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 directory with a literal 
newline in order to identify a potential upgrade problem, part of the 
proposal was to add a new opendir2() interface modeled after BSD to 
allow use of flags while opening the directory.  Of course, POSIX would 
only specify flags related to filtering newlines, or maybe even ad a 
DTF_NODOT flag for skipping the '.' and '..' entries, while leaving the 
existing BSD flags for DTF_HIDEW and friends for implementation 
extensions (BSD would still support whiteout controls, but it wouldn't 
be part of the POSIX opendir2() interfae).

I guess my concern here is whether we should be careful with what we rip 
out, in case we later want to add back in whiteout support, and to make 
sure we don't have any conflicts with existing or future opendir2() 
functions.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org