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.
