Comment 1 for bug 398199

Lucius wrote:
> Public bug reported:
>
> I updated Bazaar on Windows Server 2008 from 1.13-1 to 1.16.1. Client
> has been on 1.16.1 prior to server update. Since then, client returns:
>
> bzr: ERROR: Server sent an unexpected error: ('error', 'Length of base must be equal or exceed the platform mi
> nimum url length (which is 11)')
>
> Falling back to 1.13-1 on server resolves this error.
>
> Any idea, why this error is happening and how to correct it?

Hmm. That error comes from bzrlib.urlutils.file_relpath, which I think is only
called by LocalTransport.relpath. So apparently there's a LocalTransport object
with a base URL shorter than “file:///C:/”, which is meant to be impossible on
Windows.

Unfortunately the error doesn't tell us what the problematic URL is. We should
improve the error so that it includes this info, i.e. apply this patch:

=== modified file 'bzrlib/urlutils.py'
--- bzrlib/urlutils.py 2009-04-24 05:08:51 +0000
+++ bzrlib/urlutils.py 2009-07-12 06:25:28 +0000
@@ -75,9 +75,9 @@
     This assumes that both paths are already fully specified file:// URLs.
     """
     if len(base) < MIN_ABS_FILEURL_LENGTH:
- raise ValueError('Length of base must be equal or'
+ raise ValueError('Length of base (%r) must equal or'
             ' exceed the platform minimum url length (which is %d)' %
- MIN_ABS_FILEURL_LENGTH)
+ (base, MIN_ABS_FILEURL_LENGTH))
     base = local_path_from_url(base)
     path = local_path_from_url(path)
     return escape(osutils.relpath(base, path))

Perhaps the new server-jail code since 1.13 is somehow tripping over this?
Although I'd expect that to use a ChrootTransport...

In the meantime you could try adding -Dhpss to the client, which will cause the
client to log the smart server conversation to the .bzr.log (“bzr --version”
will tell you where that log file is kept). It would be helpful to see which
request is triggering this error.

Hmm, I think the definition of either urlutils._win32_local_path_to_url or
urlutils.MIN_ABS_FILEURL_LENGTH is buggy: _win32_local_path_to_url('/') will
return “file:///”, which is clearly less than 11 (MIN_ABS_FILEURL_LENGTH on
Windows). That may be the root cause of this bug (and if so was there in 1.13
too, but purely by luck the offending code path wasn't being hit in 1.13).

Thanks for the bug report!