Re: fts finds no files under mingw

[kodis]

On Sun, Feb 01, 2009 at 01:36:59PM +0100, Jim Meyering wrote:
> address@hidden wrote:
> > I've found a problem with the gnulib fts module.  When using the mingw
> > cross compiler, the fts_read routine never finds any files or
> > directories other than the directories supplied to the preceeding
> > fts_open call.  It seems that this will happen on any platform that
> > doesn't have a working dirfd function available.
> >
> > I've traced the problem down to the dirfd call around line 1160 in
> > fts.c, in the internal fts_build routine, after the comment block
> > containing the admonition that "This is all fairly nasty."
> >
> > After getting a valid DIR *dirp, the line "int dir_fd = dirfd(dirp);"
> > gets a dir_fd value of -1, but with an errno value of 0.  This happens
> > because the dirfd.m4 macro recognizes that there's no way to get the file
> > descriptor associated with an open DIR* on this platform, and so
> > #defines the return value of dirfd to always be -1.
> >
> > This in turn results in dirp being set to NULL, which prevents the
> > following readdir loop from being run to generate the list of files in
> > the directory.
> 
> I see a dd_handle member in the mingw declaration of "DIR",
> but it's not clear that it's a file descriptor.
> 
>       /* _findnext handle */
>       long dd_handle;
> 
> To find out, you can make this change to your configure file
> (or to m4/dirfd.m4, then regenerate configure)
> 
> -     for ac_expr in d_fd dd_fd; do
> +     for ac_expr in d_fd dd_fd dd_handle; do
> 
> and let us know if it helps.

Sorry Jim, but that doesn't help.  I modified dirfd.m4, made
maintainer-clean, reconfigured and rebuilt with identical results.

To find out what was happening, I took all of the gnulib code out of
the picture by using the i686-pc-mingw32-gcc compiler to directly
compile a simple test program, and found that the mingw opendir
routine sets the dd_handle to -1 itself.

    #include <dirent.h>
    #include <errno.h>
    #include <stdio.h>
    int main(int argc, char **argv)
    {
      char **path, *paths[] = { ".", "m4", "lib", NULL };
      for (path = paths; *path; path++)
        {
          DIR *d = opendir(*path);
          printf("%p, %ld, %d: (%s) %s\n",
            d, d->dd_handle, errno, d->dd_name, *path);
        }
      return 0;
    }

    Z:\home\kodis\fts> a
    00116A68, -1, 0: (Z:\home\kodis\fts\*) .
    00116CB8, -1, 0: (Z:\home\kodis\fts\m4\*) m4
    00116F08, -1, 0: (Z:\home\kodis\fts\lib\*) lib

It looks like the file descriptor returned by dirfd is used mainly by
fts_safe_changedir to allow fts to work correctly even when parts of
the file system are changed while being traversed.  I wonder if a
fallback to the less robust changing directory by name would be the
appropriate fix here?

-- John Kodis.