Andy Levy wrote on Tue, Apr 26, 2011 at 06:26:47 -0400:
> On Fri, Apr 22, 2011 at 11:04, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> > Andy Levy wrote on Fri, Apr 22, 2011 at 10:56:14 -0400:
> >> But our authz file is written as [Code:/path] and when committing, we
> >> get 403 Forbidden errors because no rules match - the user is
> >> committing to code and the rule checks for Code, case-sensitive.
> >>
> >> It's an easy enough fix on the client side, but it is an annoyance.
> >
> > I'm willing to accept that as a bug report, by the way. The
> > before-the-colon section is defined as 'the basename of the repository
> > directory', so it seems logical to me that it would be case-sensitive if
> > the repository is on a case-insensitive filesystem (regardless of OS).
>
> I've read this a half-dozen times and I'm still missing something, I'm
> just not understanding it.
>
Consider this setup:
% svnadmin create /path/to/foo
% svn mkdir -mm file:///path/to/foo/bar
% svn mkdir -mm file:///path/to/foo/BAR
% cat <<EOF > /path/to/authz-file
[FOO:/bar]
* = r
root = rw
EOF
%
On a case-sensitive filesystem, the [FOO:/bar] clause refers to
a repository called 'FOO', which, in general, is not the same as 'foo'.
On a case-insensitive filesystem, ./foo and ./FOO refer to the same
object, therefore --- I argued --- it makes sense to respect both
[foo:/bar] and [FOO:/bar] entries in the authz file when a request to
a repository named *either* 'foo' or 'FOO' is seen.
The paths within the repository (such as '/bar') are always case-sensitive.
(Using terminology from trunk's svn_dirent_uri.h, in the authz file
entry [FOO:/bar], 'FOO' is a dirent and 'bar' is an fspath.)
Is that clearer?
> I'd be hesitant to submit as a proper bug report as we're running
> 1.5.x in production and I haven't tested with a current release. I
> won't be able to put any time into testing against 1.6x. for another 3
> weeks due to a project. Unless my previous email is documentation
> enough to go on.
>
> > Is it httpd-specific, or does it also happen with svnserve?
>
> We've never run svnserve, so I couldn't say.
Okay, thanks.
Received on 2011-04-26 12:48:57 CEST