On Fri, May 8, 2020 at 7:41 PM Johan Corveleyn <jcor...@gmail.com> wrote: > > Op vr 8 mei 2020 16:25 schreef William A Rowe Jr <wr...@rowe-clan.net>: >> >> On Fri, May 8, 2020 at 4:50 AM Johan Corveleyn <jcor...@gmail.com> wrote: >>> >>> On Fri, Apr 24, 2020 at 1:59 AM Johan Corveleyn <jcor...@gmail.com> wrote: >>> > >>> > On Wed, Apr 15, 2020 at 4:48 PM Johan Corveleyn <jcor...@gmail.com> wrote: >>> > > >>> > > On Wed, Apr 15, 2020 at 3:51 PM William A Rowe Jr <wr...@rowe-clan.net> >>> > > wrote: >>> > > > >>> > > > Interesting. >>> > > > >>> > > > Not being familiar with the subversion code, it would be helpful to >>> > > > see what args >>> > > > are being passed to the offending (offended) apr_stat call, so we can >>> > > > investigate >>> > > > the behavior of APR 1.7.0 (or trunk) further. >>> > > >>> > > Understood. I'll try to dig into this a bit in the coming days. >>> > >>> > Okay, I finally got around to this. >>> > >>> > Subversion indeed performs an apr_stat call with the following flags [1]: >>> > >>> > apr_int32_t wanted = APR_FINFO_TYPE | APR_FINFO_LINK >>> > | APR_FINFO_SIZE | APR_FINFO_MTIME; >>> > >>> > The call to apr_stat happens on line 4464 in libsvn_subr/io.c [2]: >>> > >>> > status = apr_stat(finfo, fname_apr, wanted, pool); >>> > >>> > Apparently this call succeeds with apr 1.6.5 (on Windows), with >>> > fname_apr="C:/" and wanted as above (I added a screenshot from the VS >>> > Debugger to illustrate). The returned filetype is APR_DIR, etc ... >>> > >>> > But the call fails with apr 1.7.0, returning status == 720002 (see >>> > second screenshot, FWIW). Is Subversion doing something wrong here? >>> > Passing incorrect flags or something like that? >>> > >>> > [1] >>> > https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_subr/io.c?revision=1875971&view=markup#l3149 >>> > [2] >>> > https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_subr/io.c?revision=1875971&view=markup#l4464 >>> >>> I can't debug further into APR itself at this time, I'm afraid. Is >>> there anything else I can do? I'm not sure what the return code 720002 >>> means as a result of apr_stat(). >>> >>> Is anyone able to reproduce this issue with APR 1.7.0 with a >>> test-program merely calling apr_stat() on the root of a drive, with >>> the flags >>> >>> APR_FINFO_TYPE | APR_FINFO_LINK | APR_FINFO_SIZE | APR_FINFO_MTIME >>> >>> ? >>> >>> At this point it's not even clear to me whether this problem is >>> Windows-specific, or can also be reproduced on Linux / Unix, if you >>> call it on "/". >>> >>> If it helps I can file an issue in Bugzilla, if you guys want me to. >> >> >> I'll pursue this further on Monday and see if we can offer some workaround >> for drive-root stat calls in apr itself.
Gentle nudge ... a Friday seems ideal for this kind of work, right? ;-) TIA, -- Johan
