What was lost in apmail tmp/ full ...

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

Here's the delta of what was lost with cvs.apache.org filling up...

I introduced APR_UNKFILE to distinguish files we don't know about
from NOFILE.  I introduced tests for DIRENT_INODE and DIRENT_TYPE
to identify the dirent members for inode and filetype.  And I updated
the dir.c code for unix to take advantage of those changes, as well
as covered the UNKFILE condition in apr_stat.

Bill

Re: What was lost in apmail tmp/ full ...

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

At 01:21 AM 12/14/2002, William A. Rowe, Jr. wrote:
>--- file_io/unix/dir.c  1 Jul 2002 14:04:58 -0000       1.64
>+++ file_io/unix/dir.c  14 Dec 2002 05:55:03 -0000      1.65
...
>         ret = apr_lstat(finfo, fspec, wanted, thedir->pool);
>...
>     }
> 
>     if (wanted && (ret == APR_SUCCESS || ret == APR_INCOMPLETE)) {
>         wanted &= ~finfo->valid;
>-        ret = APR_SUCCESS;
>     }

This little bit above was a bug... if a given platform didn't support a given 
field from wanted... APR_INCOMPLETE remains the correct result code.
Not that it matters because we didn't look at ret again.

>+    finfo->name = apr_pstrdup(thedir->pool, thedir->entry->d_name);
>     finfo->valid |= APR_FINFO_NAME;
>-    /* XXX: Optimize here with d_fileno, d_type etc by platform */
>-    finfo->name = thedir->entry->d_name;

This too was a bug... we must pstrdup since one apr_dir_read later
we've clobbered finfo->name.  No other API makes things 'disappear'
behind another access.  The pool scope is all that matters, until
it falls out of scope, any string we return should remain available.

With the introduction of DIRENT_TYPE and DIRENT_INODE I stand
prepared to deal with platform bogosity.  If it doesn't pick these up
correctly on your platform please let me know.

Bill