I'm pursuing something like the attached patch. Only one test fails, which I presume devolves back to the /. root comparison (so the data directory comparison is good.) The stat/getfileinfo comparison doesn't alert if the info can't be retrieved from one or the other call, which isn't good (the availability bits should be identical.)
testfileinfo : -Line 105: apr_stat and apr_getfileinfo differ in protection FAILED 1 of 7 Failed Tests Total Fail Failed % =================================================== testfileinfo 7 1 14.29% Out of cycles to dig deeper today, but just wanted to leave an update that something interesting is going to have to happen here to delve into the "root device" vs a simple "root directory".. On Thu, Apr 9, 2020 at 11:31 AM William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Thu, Apr 9, 2020 at 8:01 AM Johan Corveleyn <jcor...@gmail.com> wrote: > >> On Thu, Apr 9, 2020 at 1:20 PM Nick Kew <n...@apache.org> wrote: >> > > >> > > The below report about a problem with Subversion working on 'subst'ed >> > > drives (Windows), seemed to be related to a change in APR 1.7.0 >> > > (https://svn.apache.org/r1855950), >> > >> > That fixed a bug PR#47630 that had been extensively discussed in >> > bugzilla and shows as having 22 watchers - that's a lot of interest! >> > >> > Does that discussion not throw any light on your issue? For example, >> > Michael Schlenker's comments there refer to that bug affecting SVN. >> >> Thanks, I've read through that issue in Bugzilla now. >> >> It definitely seems like a useful improvement for proper support of >> (different types of) reparse points on Windows. I'm not saying this >> bugfix needs to be reverted. And indeed, Michael Schlenker's comments >> point to a specific problem affecting SVN (in combination with Windows >> Data Deduplication, which creates reparse points with tag >> IO_REPARSE_TAG_DEDUP). So in general this is a step forward, and will >> probably benefit SVN for use on these specific types of Windows >> systems. >> >> However, I think this also broke something (or at least inadvertently >> changed something) related to the usage of "SUBST" (as in 'SUBST G:\ >> D:\Development\TestWC'). The usage of "subst" is not mentioned >> anywhere in PR#47630, so perhaps the compatibility with / impact on >> subst was overlooked? I'm not an expert at all, but from what I could >> find with a quick internet search, "subst" is very old (from MSDOS >> times), and it seems it's not the same as a junction (? not sure about >> the relation between subst and reparse points in general). In any >> case, it's not clear to me that the fix for PR#47630 intended to >> change something for "subst". >> > > That's very likely, and this can be researched further to dig up exactly > how > subst is handled. (As you mention, it hasn't been common since the > introduction > of proper junction and directory/file symlinks.) > > It appears that the root directory is always problematic for an svn > checkout > (actually, most checkouts were problematic on svn when junctions or > symlinks > were in play on windows.) Looks like some additional special handling is > going > to be required even with queries on c:\ (a real, not a substituted volume > root.) > > Can you successfully `svn co {repos} /` on linux? Hoping to understand the > scope of the issue. > > >
apr-root-stat-test.patch
Description: Binary data
