> > 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 _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------
