Re: GDir as DIR replacement - patch

[Owen Taylor <otaylor redhat com>]

Hans Breuer <hans breuer org> writes:

> >   What makes this a special chunk of functionality?
> >
> It has long-time lived in glib/win32 under its original name.
> Recently Tor decided to remove it to prevent namespace clashes.
> 
> That introduces the requirement to handle DIR emulation in about
> 10 projcets (88 occurences of opendir in my tree). It can be done 
> (and partly already is) but IMHO it's a mess to include and link 
> it the same way if there is one place where it belongs :-)

OK, I think it makes sense to go ahead and squeeze this in. Will
you be able to do another version of the patch in the next day
or so? I'm going to do 1.3.11 on Tuesday, and we'd really like
to have *all* API stuff done in that release.

> > - NSPR's readdir() has flags "SKIP_DOT, SKIP_DOT_DOT,
> >   SKIP_BOTH, SKIP_HIDDEN". I think most uses of readdir
> >   do want SKIP_BOTH, so it could be considered convenient
> >   to not have to put the strcmp()'s in each usage.
> >   OTOH, it could be considered bloat since you _can_
> >   do the strcmp. (Actually, I'd almost say that 
> >   you should just always skip . and .. since if you
> >   want them, you know they are there, and otherwise
> >   they are just an invitation to infinite loops.)
> >
> Even some combination with glob or fcntl may be nice and
> returning stuff in glib data structures; which obviously
> is all 2.2 stuff if desired.

Thinking about this, why don't we do:

 g_dir_open (const gchar *path, guint flags, GError **error);

With @flags being reserved for the future. And make g_dir_read_name()
_not_ return "." and "..", since it is never useful to include
them while listing a directory. If we are going to tell people
to use g_dir_open() not opendir() on Unix, there at least should be _some_
advantage of DIR *.

We can later add G_DIR_INCLUDE_DOTDOT, G_DIR_SKIP_HIDDEN or whatever
if that proves necessary.
 
> >>   entry = readdir (dir->dir);
> >> 
> >>   if (entry != NULL)
> >>     return entry->d_name;
> >> 
> >>   return NULL;
> >> }
> >
> >I seem to remember on some systems, if you open a non-directory,
> >opendir() suceeds and readdir() fails with ENOTDIR. (I'm
> >sure that the contrary works this way - if you open() a
> >directory, than read() fails with EISDIR()). So perhaps
> >we need a GError argument here?
> > 
> It would additional give symmetrie on the remaining three
> g_dir functions.

Hmmm, I did some more research on this and it looks like this isn't
a problem - opendir() has traditionally failed immediately even
if that requires an extra stat() and is specified to do so in
Unix98. (and presumably POSIX as well.)

With that in mind, I think it would be better not to include the
GError * here. Also, I think we should omit the GError * from
g_dir_close(), because again there are no likely errors that would
occur when using closedir through GDir. The two ones I saw in a survey
of manual pages were:

 EBADF:  Bad file descriptor
 EINVAL: Mixed 32 and 64 operations on the same descriptor
     
Both are not going to happen with GDir.

Making it look like people need check for failure when it can't occur
makes it more likely that they will omit to check for failure
when they _should_ be checking for failure.

Regards,
                                        Owen