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.
