The remaining apr_stat issues

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

With the patch applied, it's time for me to jump on some other bugs, and for 
folks interested to begin to optimize by platform and finfo required.
[Hint: look for APR_FINFO_NORM to find those in apache that are not optimized.]
If we won't fall over without the particular field (such as 

Note there are unix-specific optimizations of apr_dir_read we should eventually
employ.  Since the file case semantics for case insensitive file systems
is most -easily- implemented using the apr_dir_read() until inodes match, that
FreeBSD d_fileno dirent member looks awfully tempting :-)

I believe we have three lingering issues that should have some resolution:

1. It is the caller's reponsibility of the stat functions to provide the fname,
   and they may pass something off the stack.  By the time they return, it's
   hosed.  If it's passed on, it's hosed.

   They can do what I've done in OS2 and Unix - which is to clear the info.fname
   member upon return.  But -what- if we actually create the apr_file_t member in
   the process???  It will absorb this stack allocated cruft, and noone may notice
   till much, much later.

   Obvious solutions, other than to apr_pstrdup() the file on apr_open() (if we
   don't already do so?)

2. We need resolution.  Everyone is arguing for the error reporting to be easy
   to use.  That means if you need certain fields, they must be present.  If you
   don't care, you don't want to circumnavigate the extra status code.  I have
   a really easy solution.  The old-style stat constant APR_FINFO_NORM (rename it
   if you hate it) and APR_FINFO_DIRENT can set the highest bit, APR_FINFO_BEST_TRY, 
   that tells this family of functions that we are looking for best compatibility,
   but not to fail if the usual posix answers aren't part of this OS.

   Anything other than APR_FINFO_NORM or APR_FINFO_DIRENT (or a set of options with
   the APR_FINFO_BEST_TRY bit) will fail with the APR_INCOMPLETE warning.  It's not
   an error - the stat(), findfile() or readdir() call has succeeded, but you can't
   have that info on this Platform.

   There is yet -another- error exception.  What do we do when the user has asked
   to apr_stat() a file's user/group/perms _which they don't permission to read the
   security attributes of_???

   This is very real on WinNT, where you can browse a directory, but not see what
   your own permissions really are.  Security by obscufication.  The conflict is
   that we are expecting the good old unix style APR_FINFO_NORM to try to return
   the user/group/perms, so do we fail with a permission denied error?  Starting
   to miss those earlier designs of apr_status_t again.

3. Add extra padding, pass an apr_finfo_t **info instead and have us do so (since
   the type is not complete, there are -no- guarentees), implement the MS "we have
   so many bytes available" mechanism, or some other means of setting aside the
   right amount of apr_finfo_t space.

   There are two related issues, one is the allocation of strings (fname and name)
   that could be lost (see 1. above), and their expected lifetimes (do we guarentee
   the name until the next readdir, or longer?)  It's related, since -if- we always
   allocate pool memory for each finfo, we can overallocate by the length of the
   names in a pretty expedient manner.  Or not, you decide.

   The other is the lifetime of the apr_file_t pointer.  If we let the caller 
   allocate, must they zero the apr_finfo_t before calling us?  Either way, do we 
   assume the apr_file_t has meaning, and preserve it or close it then and there?
   If we agree to always wipe and create a new apr_file_t pointer

RE: The remaining apr_stat issues

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Monday, January 22, 2001 10:49 PM
> 
> With the patch applied, it's time for me to jump on some other bugs, and for 
> folks interested to begin to optimize by platform and finfo required.
> [Hint: look for APR_FINFO_NORM to find those in apache that are not optimized.]
> If we won't fall over without the particular field (such as 

... retrieving the owner of the file for the SSI username variable.  It really
wouldn't kill us if we had to substitute <Unknown User>, so omit that flag
from the apr_stat call and test fileinfo.valid & APR_FINFO_USER.

Sorry I'm near nodding off.  Clearly I need a bit of rest.  Guten abend.