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 >