In case we are less than clear here,
from apr's getfileinfo, stat, lstat and readdir API, the system is to return
only those components listed in the 'wanted' argument and those that come
FOR FREE. If processing time would increase, to retrieve 'unwanted' info, then
those will not be marked as not retrieved.
ANY PLATFORM may refuse to provide information that it can't obtain. Therefore
APR_EINCOMPLETE will signal missing bits from the 'wanted' mask that aren't
present in the ->valid results.
I need to review the proposed changes carefully, but be warned I will veto any
change which 'makes up' answers that don't correspond to the true values of
these fields. APR isn't cygwin, no results are 'invented' here. They all
correspond to true data or they are not returned at all.
Bill
D.J. Heap wrote:
On 2/10/06, Garrett Rooney <[EMAIL PROTECTED]> wrote:
[snip]
Unfortunately no, this (along with the proposed backport of that other
revision, IIRC) has not yet been committed. I haven't had a chance to
dig into it, and nobody with any win32-fu has looked at this AFAIK.
So if I understand correctly, 'incomplete' is a fatal error and
Subversion (for example) should not attempt to deal with it and
continue. And this set of patches fixes apr to do that on Win32, but
hasn't been verified to look and work correctly yet?
I should have some time this weekend to help, but I'm a bit unclear on
what the situation is if the above is not right.
BTW, I can't seem to find a 'real' release of Apache 2.2 for
Windows...is there one out yet?
Sure, there's a source code tarball. Feel free to build.
Most users need to run Apache 2.2.0 + patches, and even on win32 apply
additional build patches, so mirroring the 2.2.0 tarball with a broken
binary wasn't high on my priority list. Releasing the next apr, apr-util
and httpd IS high on my priority list, which is why I'd spent so much time
in the past two weeks on bugs.
Glad this one 'resurfaced' during my bugzilla review :) I'll investigate.
Bill
