Michael Osipov wrote on Fri, Feb 05, 2016 at 23:34:16 +0100:
> Am 2016-02-05 um 22:10 schrieb Ivan Zhakov:
> >'vn: E160033: Invalid name for FS type 'fsfs
> >]]]
> We know now that the repo is mangled. The output of the last line is broken
> btw. It should read "svn:... 'fsfs'" but it reads "'vn:...'fsfs". Shall a I
> create a JIRA issue for that?
Yes, please. We should be escaping the \r character rather than
printing it literally.
The root problem is that we just use the equivalent of apr_psprintf("The
value is '%s'", value) to enter replaceables into error messages; we
don't escape the argument to %s, nor do we use a format code (like
the %r and {!r} of Python's string formatting or the %q of the printf(1)
builtin of bash and zsh) that implements single-quoting-and-escaping itself.
>>> print("The value is '%s'." % ('fsfs\x0D',))
'.e value is 'fsfs
>>> print("The value is %r." % ('fsfs\x0D',))
The value is 'fsfs\r'.
> I have unzipped the repo on:
> FreeBSD bsd10 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12
> 15:26:37 UTC 2015 root_at_releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC
> amd64
>
> and I receive the very same error as you do.
That's not surprising: the fs-type file has a CRLF line ending, and on
FreeBSD the CR wouldn't be removed.
Does 'svnadmin create' use CRLF for the fs-type file on windows? It
should probably use LF to make the format entirely platform-independent.
> Additionally, I just created a VM with Windows 7 SP1 32 bit and installed
> Subversion 1.9.3 and the test repo. The svn client crashes here too.
For what it's worth, I wouldn't call it a "crash": it's not an abnormal
program terminal (such as an exception or a signal) but a metadata
validation doing its job.
> I do not understand why it is not failing for you. Can you retry with the
> binaries provided by CollabNet? Or any other idea why there is a disparity?
Subversion doesn't request binary mode for opening/reading the fs-type
file (doesn't request APR_BINARY which, I imagine, is a portable wrapper
for the "b" mode flag of fopen()). Could that explain why you see
different binaries behaving differently?
Cheers,
Daniel
Received on 2016-02-07 01:22:08 CET