[ I didn't see Bill resend this to the list, so I'm doing it now... ] ----- Forwarded message from "William A. Rowe, Jr." <[EMAIL PROTECTED]> -----
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]> Subject: RE: New directory API... To: "'Greg Stein'" <[EMAIL PROTECTED]> Date: Mon, 22 Jan 2001 08:36:02 -0600 > From: Greg Stein [mailto:[EMAIL PROTECTED] > Sent: Monday, January 22, 2001 4:23 AM > I'd say: have the user pick up the finfo->filehand if available and call > apr_getfileinfo() for the bits they need (with a new structure). finfo->filehand should be somewhat opaque. Some platforms may not set it up (if they didn't create a 'file' to access the fileinfo.) Some platforms (OS X) will have some other semantic. Unix will look at finfo. We should either implement apr_dir_fileinfo(finfo, wanted, thedir) _or_ create an apr_more_fileinfo(finfo, wanted) that can be used for incremental info from stat/lstat/getfileinfo or readdir results. > > 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. > > Yup. I'd guess that most apps will simply do a stat rather than trying to > really optimize the case. *If* optimization is important to them at that > point in the code path, then yes: they'll compute a new wanted flag. > Actually, it won't be too difficult: > > wanted = MY_WANTED_FLAGS & ~finfo.valid; No need - with either the apr_dir_fileinfo or apr_more_fileinfo calls. They would just look at .valid. > > In our first bs session about the finfo idea, we kicked > > around the idea of -incrementally- calling apr_stat. > > Shades of apr_open. I really don't think we want to try this. Agreed - seperate function required. > > 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.) > > Third choice: let the caller deal with a concat if necessary. They can > optimize the snot out of it, if that is important to them. > Other apps will simply do the apr_pstrcat() and be done with it. We ourself need to concat -if- we actually do something with it ourselves. (you've been arguing up till now against user's code bloat.) The suggested apr_dir_fileinfo() call does so, but would use stack to keep from bloating the pool. If you will use the stuff later, call apr_stat after concating yourself; if you never need the full path, call apr_dir_fileinfo() (which also skips the effort of requerying the known finfo.) We must simply document that apr_dir_fileinfo() -requires- the original apr_finfo_t buffer from the apr_readdir() call. I'm left with one question - would we rather have an incremental apr_more_fileinfo() that can ask "what do we have here?" and fill in the blanks, or a narrowly focused apr_dir_fileinfo() that handles that specific case? Bill ----- End forwarded message ----- -- Greg Stein, http://www.lyra.org/
