On Wed, 17 Jul 2019 at 22:12, Steve Hay <steve.m....@googlemail.com> wrote:
>
> On Wed, 17 Jul 2019 at 15:04, Branko Čibej <br...@apache.org> wrote:
> >
> > On 17.07.2019 10:18, Steve Hay wrote:
> > > On Tue, 16 Jul 2019 at 18:31, Steve Hay <steve.m....@googlemail.com> 
> > > wrote:
> > >> On Tue, 16 Jul 2019 at 14:53, William A Rowe Jr <wr...@rowe-clan.net> 
> > >> wrote:
> > >>> On Tue, Jul 16, 2019 at 8:10 AM Steve Hay <steve.m....@googlemail.com> 
> > >>> wrote:
> > >>>> I'm in the process of preparing a new mod_perl release and have run
> > >>>> into a few test failures on Windows 10 which are caused by apr_stat()
> > >>>> sometimes returning APR_INCOMPLETE (70008).
> > >>>>
> > >>>> I'm only getting this on Windows 10. If I run the same build of
> > >>>> everything on Windows 7 then everything is fine. I've built everything
> > >>>> from scratch with VS2019. I get the same behaviour with VS2015.
> > >>>>
> > >>>> I'm using apr-1.7.0 / apr-util-1.6.1. Is it worth trying the latest
> > >>>> dev versions?
> > >>>
> > >>> Would you retest with apr-1.6.5? Minor changes to the handling of 
> > >>> symbolic
> > >>> links (junction/reparse points) on Win32 in 1.7.0 may be to blame.
> > >>>
> > >>> (Yes, I understand that you are not looking at a symlink in this case.)
> > >>>
> > >>>
> > >> I've built everything in a fresh directory tree in exactly the same
> > >> way as before but using 1.6.5 instead of 1.7.0 and it behaves the
> > >> same.
> >
> > I suggest you turn off your virus scanner and try again.
> >
> > Windows virus scanners are notorious for blocking access to newly
> > created files for an unreasonable amount of time, causing downstream
> > operations to fail. In Subversion, we had to code an exponential-backoff
> > retry loop into our IO operation wrappers, but only on Windows.
> >
>
> Unfortunately, I'm on a PC controlled by domain admins and I'm unable
> to disable the virus scanner.
>
>
> More importantly here (to remove Perl from the equation) the attached
> test.c program also works every time, but the APR-equivalent testapr.c
> fails every time.
>
> Can anyone else reproduce this?
>
> There either seems to be something actually wrong in apr_stat() or
> else it's just trying to be too clever and do too much and maybe needs
> some backoff & retry logic in it in order to succeed in that, since it
> currently seems useless compared to C's stat() and Perl's stat() under
> my set of conditions, which are not at all unusual (simply: Windows 10
> with AV turned on).

Stepping through that testapr.c program I see the first thing that
goes wrong is here:

> libapr-1.dll!resolve_prot(apr_finfo_t * finfo, int wanted, _ACL * dacl) Line 
> 124 C
  libapr-1.dll!more_finfo(apr_finfo_t * finfo, const void * ufile, int
wanted, int whatfile) Line 356 C
  libapr-1.dll!apr_file_info_get(apr_finfo_t * finfo, int wanted,
apr_file_t * thefile) Line 561 C
  libapr-1.dll!resolve_ident(apr_finfo_t * finfo, const char * fname,
int wanted, apr_pool_t * pool) Line 161 C
  libapr-1.dll!apr_stat(apr_finfo_t * finfo, const char * fname, int
wanted, apr_pool_t * pool) Line 618 C
  testapr.exe!main() Line 21 C

The previous GetEffectiveRightsFromAclW() call to get the
APR_FINFO_UPROT worked, but this second call to get APR_FINFO_GPROT
has failed. The third call to get APR_FINFO_WPROT also fails.

The error from GetEffectiveRightsFromAclW() both times is 8519
(ERROR_DS_GLOBAL_CANT_HAVE_CROSSDOMAIN_MEMBER): A global group cannot
have a cross-domain member.

That's why not everything requested (APR_FINFO_NORM) has been marked
as valid, so the final "return ((wanted & ~finfo->valid) ?
APR_INCOMPLETE : APR_SUCCESS);" gives us APR_INCOMPLETE.

I'm also confused why apr_stat() is doing this twice (once from line
617: resolve_ident() -> apr_file_info_get() -> more_finfo() ->
resolve_prot(), and once again on line 791: more_finfo() ->
resolve_prot()) given that on line 290 it is commented that "this
request is incredibly expensive".

Reply via email to