apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject RE: New directory API...
Date Mon, 22 Jan 2001 06:45:56 GMT

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

Yeah, but in the other case, they are left grabbing information they
didn't want, and that could be expensive.  Take mod_autoindex.  We do a
quick readdir, and then use the filename for a sub_request.  If we put the
stat in the readdir call, then we end up stating twice.  Once in the
readdir and once in the sub_request.  If we leave the stat out, then we
only stat in the sub_request.  In my mind that behaviour is
non-negotiable, but I am always willing to be convinced.  :-)

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

preallocating a buffer won't work, because we end up with thread-safety
issues.  Not a problem for Apache, but for other
programs... boom!  :-)  Let me sleep on this tonight.


Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131

View raw message