On Fri, Nov 27, 2020 at 10:30 AM Johan Corveleyn <jcor...@gmail.com> wrote:
>
> 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!

Hi,

Any news on this issue?

Just as a FYI: in SVN we're getting close to starting the release
train on 1.14.1. Would be nice for our Windows users to be able to
include a 1.7.x APR with this issue fixed ;-).
(Of course I know I don't get to dictate any project's release
schedule, not to mention anyone's time spent on an issue -- I know I'm
not doing the work here ... just consider this some meta-data in case
it matters :-))

-- 
Johan

Reply via email to