CollabNet has a customer who's having trouble with locking files with Chinese names. They are hosting with Apache, and when they attempt to lock such a file, the server process hangs and the client sits doing nothing until a timeout kicks in and breaks the connection. (I can easily reproduce the situation myself, too.)
The problem occurs as Subversion attempts to convert all the UTF-8 pre-lock
hook parameters (which include the to-be-locked path) into the locale's
character set before using them to invoke the hook script itself. The
problem is that even though the system locale is a UTF-8-ish one, Apache has
set the locale to the baseline "C" locale. UTF-8 Chinese characters can't
be represented in mere ASCII, so the conversion fails. Subversion (on the
server) creates an error when svn_io_start_cmd() is trying to convert those
hook parameters, and stores the error in an 'err' local variable in
run_hook_cmd():
err = svn_io_start_cmd(&cmd_proc, ".", cmd, args, FALSE,
stdin_handle, result ? write_outhandle : null_handle,
write_errhandle, pool);
But this codepath still allows us to fall into this future block of code,
where we're trying to read output from the hook (which, by the way, was
never actually launched):
if (result)
{
svn_stringbuf_t *native_stdout;
SVN_ERR(svn_stringbuf_from_aprfile(&native_stdout, read_outhandle,
pool));
I believe this is the cause of the Apache process hang. And I suspect that
we can fix this.
But what about original problem with encodings? If I recall correctly,
Apache is intentionally locale-ignorant. Like, not just "I don't know about
the system locale", but "I'd like to ignore the system locale. On purpose.
For reals." Would an appropriate workaround for this problem be to
introduce a mod_dav_svn configuration directive which allows admins to
dictate the locale of their hook environment?
--
C. Michael Pilato <cmpil...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
