Re: fdopendir closes the file descriptor on MinGW

[David Grayson]

Paul, Eli, and Eric: thanks for looking into this and providing
information about the problem.

On Thu, Mar 19, 2015 at 12:18 PM, Paul Eggert <address@hidden> wrote:
> On 03/19/2015 09:19 AM, Eli Zaretskii wrote:
>> I suggest the following simpler
>> change instead:
> Thanks, I installed that, with a briefer code comment.

I have not tested Eli's simpler change, but I expect it would fix the
bug in grep, and the bug in by test program at the beginning of this
thread.  However, two things about that patch seem wrong to me:

1) In the specification of fdeopdir, POSIX requires that
closedir(fdopendir(fd)) will close fd, assuming fdopendir was
successful.  That patch does nothing to associate the duplicated file
descriptor to the DIR pointer, so the file descriptor will not be
closed by closerdir. This is not POSIX compliant, and I think this
would lead to memory leaks in applications that use fdopendir and
closedir.  Also, if the file descriptor has any OS-level connection to
a directory, it might cause bad side effects in Windows, like making
the directory undeletable or unmovable by other applications.  In this
way, that patch is not so different from my original bad workaround,
which was to comment out the "close (fd);" line in fdopendir, except
my workaround probably leaked memory faster.

2) It seems odd to me that inside fdopendir, Gnulib would close the
file descriptor, then follow this complicated, non-thread-safe
recursive strategy, and then at the end it would essentially realize
that the whole thing was a waste of time, and just dup the file
descriptor to recover.  I thought the whole point of the
close/dup/recursive thing was to trick the base system into using the
right file descriptor for the new DIR pointer, so that it would get
closed later by closedir.  Since that isn't the case in MinGW, don't
need the close/dup/recursive thing.  It seems like Gnulib should know
at compile time what type of system it is running on, and try to use
that to avoid doing extra work.

>From the small bits of the POSIX API that I have read (dirfd,
fdopendir, closedir), it really seems like it is suited for an
implementation where every DIR pointer (or at least the DIR pointers
created by fdopendir) must be associated with a file descriptor.  So
it would be great to get that association working.  I will look at the
older discussion about dirfd mentioned by Paul, and the
implementations of open and fchdir, and probably try to come up with a
patch some time.

--David