You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Johan Corveleyn <jc...@gmail.com> on 2020/05/08 09:50:11 UTC
Re: Subversion reports status fault on substituted drive
On Fri, Apr 24, 2020 at 1:59 AM Johan Corveleyn <jc...@gmail.com> wrote:
>
> On Wed, Apr 15, 2020 at 4:48 PM Johan Corveleyn <jc...@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.
Thanks,
--
Johan
Re: Subversion reports status fault on substituted drive
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, May 8, 2020 at 7:41 PM Johan Corveleyn <jc...@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 <jc...@gmail.com> wrote:
>>>
>>> On Fri, Apr 24, 2020 at 1:59 AM Johan Corveleyn <jc...@gmail.com> wrote:
>>> >
>>> > On Wed, Apr 15, 2020 at 4:48 PM Johan Corveleyn <jc...@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
Re: Subversion reports status fault on substituted drive
Posted by Johan Corveleyn <jc...@gmail.com>.
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 <jc...@gmail.com> wrote:
>
>> On Fri, Apr 24, 2020 at 1:59 AM Johan Corveleyn <jc...@gmail.com>
>> wrote:
>> >
>> > On Wed, Apr 15, 2020 at 4:48 PM Johan Corveleyn <jc...@gmail.com>
>> wrote:
>> > >
>> > > On Wed, Apr 15, 2020 at 3:51 PM William A Rowe Jr <
>> wrowe@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.
>
That would be great, thanks!
--
Johan
>
Re: Subversion reports status fault on substituted drive
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, May 8, 2020 at 4:50 AM Johan Corveleyn <jc...@gmail.com> wrote:
> On Fri, Apr 24, 2020 at 1:59 AM Johan Corveleyn <jc...@gmail.com> wrote:
> >
> > On Wed, Apr 15, 2020 at 4:48 PM Johan Corveleyn <jc...@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.