Interesting. Not being familiar with the subversion code, it would be helpful to see what args are being passed to the offending (offended) apr_stat call, so we can investigate the behavior of APR 1.7.0 (or trunk) further.
I had to tweak the logic of the test I presented above to ask a getfileinfo-based query. Typically, it isn't possible to open a root or directory with apr_file_open, but there is some hidden logic which could be extended to the public API for that purpose, if subversion is trying to rely on apr_file_info_get instead of apr_stat. I had to introduce that logic into the test in order to compare results between the two different code paths. Opening roots are particularly quirky because roots can be confusingly accessed as devices or directory entities. On Wed, Apr 15, 2020 at 3:45 AM Johan Corveleyn <jcor...@gmail.com> wrote: > On Fri, Apr 10, 2020 at 4:19 PM Johan Corveleyn <jcor...@gmail.com> wrote: > > > > On Fri, Apr 10, 2020 at 3:45 PM William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > > On Thu, Apr 9, 2020 at 2:48 PM Johan Corveleyn <jcor...@gmail.com> > wrote: > > >> On Thu, Apr 9, 2020 at 6:31 PM William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > >> > > > >> > 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.) > > >> > > >> Thank you for looking into this. > > >> > > >> You're absolutely right: with TSVN 1.13 (APR 1.7.0) I get the same > > >> erroneous behavior when 'svn -st'-ing a checkout to C:\ (real drive) > > >> > > >> [[[ > > >> C:\>svn st -q > > >> ! . > > >> ]]] > > > > > > > > > Here's another experiment that drives me batty... > > > > > > svn co https://svn.apache.org/repos/asf/httpd/httpd/trunk httpd-2.x > > > svn co https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4 > httpd-2.4 > > > svn co https://svn.apache.org/repos/asf/httpd/docs/trunk httpd-docs > > > ln -s httpd-docs httpd-2.4/docs/manual/build > > > ln -s httpd-docs httpd-2.x/docs/manual/build > > > (flip the args using mklink /d or mklink /j on windows) > > > > That's a bit special: you're creating embedded working copies, which > > is already special to begin with (even if they were all normal, > > separate checkouts instead of symlinks). > > There is code that tries to crawl up the tree to find the working copy > > root. Perhaps that is going wrong in this case, depending on your CWD. > > Not sure. > > > > > You'll see svn is fluxored until you change directory. A similar > ugliness > > > occurs if you attempt to check out a number of versions of httpd-test, > > > and attempt to point all of the X apache-test checkouts into a single > > > group. > > > > > > What I've determined is that apr_stat and apr_getfileinfo differ in > only > > > one aspect, that protections on a root directory are 700 or 777 based > > > on the way we dress up fprot bits from windows ACLs, or not. > > > > > >> > Can you successfully `svn co {repos} /` on linux? Hoping to > understand the > > >> > scope of the issue. > > >> > > >> Sorry, no Linux at my disposal where I'm root. But I suppose the test > > >> above with the checkout to C:\ already confirms your hypothesis. > > > > > > > > > I'm not sure what svn is doing with the '.' root entity, but it likely > made > > > some absurd assumptions about symlinks. > > > > Yes, that's very well possible. It's a difficult area I think (also: > > there is the distinction between a symlink to a working copy root, > > which just needs to be "read through" for svn commands to act upon, > > and symlinks that are part your versioned data, which need to be > > versioned and re-created as symlinks in other working copies (cf. the > > "svn:special" property) -- something which currently is not supported > > on Windows (junctions), they are just converted into a text file with > > the link reference in it ... a long standing feature request for svn). > > > > I'm afraid I don't have much expertise in that area of the svn code. > > If we need wider input on this from the svn devs, I suppose > > dev@subversion should be added back to the cc list. > > > > However: with the issue reported here there is no symlink involved > > (well, maybe sort of, with the subst case, but then it also fails on a > > plain C:\ drive root). There seems to be a change in behavior between > > APR 1.6.5 and 1.7.0 that makes svn see different information when the > > working copy root is the root of a drive. Of course, this may very > > well be svn's fault for jumping through strange hoops to work on drive > > roots, and one of those hoops may have just changed form :-). I'm not > > discounting that possibility at all. > > FYI, another data point: > I just saw a new report on the TortoiseSVN mailinglist, where a user > sees exactly the same problem with a "shared folder", where the > wc-root is the share-root: > > > https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/tortoisesvn/jgHE5_sHfFI/xOpP1Ce3AAAJ > > Quoting: > [[[ > C:\Users\ta>svn status \\computer-a\shared-working-copy > ! \\computer-a\shared-working-copy > ]]] > > I'm guessing this is the same problem with "drive-roots", just as with > subst or the root of real drives. > > -- > Johan >
