apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: New directory API...
Date Mon, 22 Jan 2001 06:24:34 GMT
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Sunday, January 21, 2001 10:39 PM
> > > -apr_status_t apr_readdir(apr_dir_t *thedir)
> > > +apr_status_t apr_readdir(apr_finfo_t *finfo, apr_dir_t *thedir)
> > 
> > The other side of the question - do we -want- the apr_readdir fn to
> > accept an apr_int32_t wanted arg, passed to stat or handled internally
> > based on the platform?  The obvious consiquence - if we pass wanted
> > as APR_FINFO_FNAME we get nothing but a filename (no stat req'd.)
> > Depending on the platform, you may have other goodies for free, or
> > you can request precisely what we need [this needs resolution of the
> > other, APR_INCOMPLETE, side of the coin.]
> I dislike combining the readdir and the stat call.  We can provide what
> comes for free, anything more should be the result of a separate stat
> call.

Alrighty then... I will live with that till we are proven wrong.  I presume 
we mean to 'reuse' the apr_finfo_t struct in the subsequent call, so we 
need to watch for any 'oops'.  Of course, the user is left testing what 
they 'wanted' twice, once to see if apr_readdir picked it up, and again to 
see if apr_stat did the second time around.  Very sub-optimal.

In our first bs session about the finfo idea, we kicked around the idea
of -incrementally- calling apr_stat.  I don't like the ambiguity.  This
is certainly the argument for it, though.  The idea is that we don't want
to call stat for something stat will refuse to provide, but we need to
tell stat that we have 'really good stuff here', and not to worry about
giving us what we already know.  Perhaps an APR_FINFO_INCREMENTAL flag
or some such.

> > > +    finfo->fname = apr_pstrcat(thedir->cntxt, 
> thedir->dirname, "/", thedir->entry->d_name, NULL);
> > 
> > This is a sub-optimal as the original.  I'd expect most apps would
> > simply accept this;
> > 
> >     finfo->fcase = thedir->entry->dname;
> That's how I originally had it.  The problem is that the testfile program
> then fails miserably.  My goal was to have the readdir function return an
> finfo with a name that we could then use for apr_finfo.  When I just used
> the thedir->entry->dname field, I couldn't do that.

Two choices.  apr_dir_fileinfo() which deals with it and merges them.
Or preallocate a buffer in the opendir of the fname length (dir name) plus
the length of the longest allowed filename, up to the limit of the total
path length.  No sense returning a name >_MAX_PATH, I already have this
exception in Win32 (and just skip over such bogus files.)

I'll have the Win32 implementation tommorow about noon for all to consider.
I'd like to see this be done so the api continues to reflect reality.  I'm
going to sleep - need rest.


View raw message