Re: fdopendir closes the file descriptor on MinGW

[Eli Zaretskii]

> Date: Fri, 20 Mar 2015 09:55:07 -0700
> From: David Grayson <address@hidden>
> Cc: Eli Zaretskii <address@hidden>
> 
> 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.

That is true, but it's a separate problem, and solving it will need
changes to dirfd and the underlying infrastructure; that's what Paul
meant by the second part of his message.  Currently, there's no way of
finding the file descriptor by the DIR pointer.

> 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.

The file descriptor is connected to the null device (see Gnulib's
'open' implementation, where it handles O_DIRECTORY), so this problem
doesn't exist.

> 2) It seems odd to me that inside fdopendir, Gnulib would close the
> file descriptor

It closes it after dup'ing it, so the directory is still open.

> 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.

Most of that code is for Posix systems.  I agree that it could be made
much simpler if it only needed to cater to MinGW, but that's not what
it's designed to do.  MinGW is just one of the supported systems, and
not the most important one (to put it mildly).  Therefore, it is
important to keep the Posix-related code logic as clear and as intact
as possible, while fixing its MinGW version.

> >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.

That's true, and that's how Posix systems work.

> 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.

Thanks in advance.