This problem can manifest itself in a number of ways, but the underlying root
issue is that httpd runs with a locale of C, the default POSIX locale, which
uses a 7 bit ASCII character set. Internally in various places in Subversion we
attempt to convert from our internal utf8 strings into native encoded strings,
which fails spectacularly under DAV when the utf8 string includes multibyte
characters because those characters cannot be expressed in 7 bit ASCII encoding.
I brought this problem up on the HTTPD dev list, and the consensus is that httpd
runs in the C locale because using the system locale (i.e. respecting the LANG
or LC_ALL environment variables via a call to setlocale(LC_ALL, "") like svn
does for all its command line programs) results in unpredictable behavior for
various functions that depend on the locale. Apparently some modules take
matters into their own hands and use setlocale to set the locale manually, but
this is very much not a recommended practice because it's a global setting and
the results are not easily predicted.
What is the end result of this?
Well, you can't use 'svn lock' on a file that has multibyte characters in its
path, because when mod_dav_svn tries to call the pre-lock hook script it needs
to pass the filename, which it tries to translate into native encoding first.
This case is even weirder, since the hook script actually runs in an empty
environment, so it has no way to know what its locale actually is because it
can't access the appropriate environment variables from the parent httpd process.
Perhaps more disturbing is that if a repository has multibyte characters in its
path (i.e. it's just in a directory that's got multibyte charactes in its name)
you can't do anything at all with it, even browsing the repository results in
errors about not being able to open the repository, the underlying errors that
show up in error_log are predictably about translating from utf8 -> native.
What's the fix? I have no idea. We can't just trust that converting to
"native" encoding is the correct thing to do in all cases, but unfortunately
we've got an awful lot of code in svn that assumes that's what it should be
doing when paths are passed from svn's internals into the outside world.
Additionally in the case of hook scripts it's not clear that converting to
native is even desireable, since the script doesn't have any way to tell what
native encoding actually is.
Bug
Critical