ko...@comcast.net wrote:
...
> BTW, it looks like the more Posixly correct action for dirfd to take
> when no file descriptor will ever be available is to set errno to
> ENOTSUP prior to returning -1. Just something to consider.
That would indeed be an improvement.
I'm about to make this change:
On Sun, Feb 01, 2009 at 05:08:41PM +0100, Jim Meyering wrote:
> ko...@comcast.net wrote:
> > 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 wonde
ko...@comcast.net wrote:
...
> 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
>
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
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
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 fun
