On Fri, Nov 27, 2020 at 2:26 AM William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Thu, Nov 26, 2020 at 3:35 PM Nick Kew <n...@apache.org> wrote:
>>
>>
>> > On 24 Nov 2020, at 18:51, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>> >
>> > Yes, I'm on it. 1.6.x and prior somewhat works. 1.7.0 does not, asking
>> > for apr_stat of a root drive. Seeing the request yesterday for a new
>> > release,
>> > I'd like the chance to fix that quirk of the Win32 API and populate the
>> > stat
>> > struct with something resembling correct info about the root mounts.
>>
>> Is the issue here that we have something that simply won't map onto
>> Windows expectations, so there is no solution that will work for Johan
>> without re-introducting PR#47630?
>
>
> Close, and no, we won't reintroduce the old defect.
>
> It's a combination of treating [C:\]"The device" specially because there is no
> concept on windows of getting the C:\ filesystem, even though it is an NTFS
> (root) directory object, with contents and context.
Just to be sure: the same reasoning goes for subst'ed drives, yes?
Say, W:\ pointing to C:\working-copy. That's also a "device" then?
>>
>> If so, perhaps what we need is an additional argument that'll switch
>> between the two behaviours (ignored on non-windows), and to
>> deprecate the existing problematic API.
>>
>> I'm reluctant to jump in here myself 'cos it's been many years since I
>> had access to a Windows machine, let alone a dev environment.
>> But it's simple enough, I guess I could hack up a "looks OK" patch
>> to do that in the absence of any alternative proposal?
>
>
> What we don't want to do is to put two different behaviors on the user.
> The fix I have on the bench is to react *when we see the anticipated error*
> and know that is should react as looking at the device not the directory,
> and "make stuff up" about the remaining fields to be filled in a consistent
> manner. What has my attention right now is authoring the tests to prove
> up success or failure in this attempt.
Can you draw inspiration from the behavior of APR 1.6.5?
>From a compatibility point of view it would make sense to look at what
values 1.6.5 returned in this case, and see if they are the way to go
(or even, if we want to go the "compat as much as possible" route,
emulate 1.6.5 as much as possible?).
Also, in line with what I said above: it would probably be a good idea
to also include a "subst" case in the tests ("subst T: C:\test";
repeat test on T:\)
Thanks for working on this!
>>
>> BTW, please don't Cc: me replies to this thread. I get it on the APR
>> dev list, and I don't need a second copy!
>
>
> :) Anyone is welcome to propose switching to httpd-dev like semantics for
> reply-to handling. What I'm curious is whether the svn-dev side of
> contributors
> have a strong feeling one way or the other, because I know httpd-dev related
> contributors all do.
Heh, sorry Nick, understood. I'm just used to hitting "reply all",
which is how it works best in svn-dev land (AFAIK). I don't know about
the other svn devs, it's just what I'm used to -- I don't have any
strong feelings about list reply behavior :-).
--
Johan
