From dev-return-1210-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Sun Feb 11 06:28:04 2001 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 36469 invoked by uid 500); 11 Feb 2001 06:28:04 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 36395 invoked from network); 11 Feb 2001 06:28:03 -0000 Errors-To: From: "William A. Rowe, Jr." To: Subject: RE: New directory API... Date: Mon, 22 Jan 2001 09:24:16 -0600 Message-ID: <001301c08487$622ea790$92c0b0d0@roweclan.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20010122022315.C704@lyra.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > From: Greg Stein [mailto:gstein@lyra.org] > 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