Joerg Wunsch wrote on Thu, 23 Jan 2020 12:44 +0100:
> My entire point is: when getting any error for ..*/.svn/wc.db, just
> stop traversing there, and proceed with the checkout (in its own
> new directory).
This change is not likely to be accepted.
As your ktrace shows, Subversion does a stat("…/.svn") which succeeds
followed by a stat("…/.svn/wc.db") which fails. One possible cause
for this behaviour is that "…/.svn/wc.db" does in fact exist, but cannot
be accessed, for whatever reason. In that case, pretending that we are
not actually inside a working copy would be the Wrong Thing to do.
However, there might be other things we could do. First, it is possible
to create nested checkouts in general, so perhaps the "Are we already
inside a working copy?" check is superfluous. That is, perhaps «svn co
$URL $dir» shouldn't check $dir's ancestors for .svn/ subdirectories.
(Checking $dir/.svn is probably fine.)
Second, the error code you got was EIO. While I think bailing out on
EIO is reasonable, there's room to argue that the second stat() call
should have returned ENOTDIR (since the path refers to a file inside
a non-existent directory) and that Subversion should have treated that
as harmless. However, on FreeBSD a plain «stat /nonexistent/foo/bar»
returns ENOENT, not ENOTDIR…
> You could construct a similar testcase without involving an automounter
> by creating a directory /.svn as root which is not accessible by any
> mere user:
> In other words, the sys admin, by creating that directory, prevents
> *any* user of the system from checking out any (new) SVN repository in
> the system. I don't believe this is intented. ;-)
The fact that a sysadmin can shoot his users in the foot is not a bug.
It's simply how Unix works. root can prevent jrandom from creating
working copies in any number of ways.
As to the fact that when you do «svn co $URL $dir» Subversion checks not
only whether $dir/.svn exists but also whether $dir is inside a working
copy, _that_ we might be able to do something about.
Thanks for including the ktrace output; it was very helpful.
Received on 2020-01-23 19:38:26 CET