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".
