On Sun, Feb 01, 2009 at 01:36:59PM +0100, Jim Meyering wrote:
> ko...@comcast.net 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.
