Sorry, I'd been pounding on a beta deliverable, it's my bad. This coming
week I have cycles to give
back to APR, CMake and other projects neglected during this crunch period.
I hope an end-of-year
(or very early January) release will meet your goals..
On Fri, Dec 11, 2020 at 6:32 AM Johan Corveleyn <jcor...@gmail.com> wrote:
> 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
>
