Merge lp:~gz/bzr/root_drive_file_url_841322 into lp:bzr
Status: | Merged |
---|---|
Approved by: | Jelmer Vernooij |
Approved revision: | no longer in the source branch. |
Merged at revision: | 6127 |
Proposed branch: | lp:~gz/bzr/root_drive_file_url_841322 |
Merge into: | lp:bzr |
Diff against target: |
58 lines (+12/-3) 4 files modified
bzrlib/tests/test_urlutils.py (+6/-0) bzrlib/transport/__init__.py (+1/-2) bzrlib/urlutils.py (+1/-1) doc/en/release-notes/bzr-2.5.txt (+4/-0) |
To merge this branch: | bzr merge lp:~gz/bzr/root_drive_file_url_841322 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Jelmer Vernooij (community) | Approve | ||
Review via email: mp+74034@code.launchpad.net |
Commit message
Fix breakage when creating a transport at drive root on windows
Description of the change
Fixes massive breakage on windows from changes to path handling aimed at smuggling extra information for colocated branch addressing into urls. There's a fun set of interactions and a couple of very minor bugs that make for some serious fallout.
Lots of operations involve speculatively opening a location, and per `BzrDir.
The simple bug is the urlutils.
if len(path) < 3 or path[2] not in ':|' or path[3] != '/':
raise errors.
'win32 file:/// paths need a drive letter')
Which ensures the string is at least three characters long then looks at the fourth character.
This only gets exposed because of the set of changes landed in r6079:
<https:/
The problems come from the added split_segment_
The last complication is in `Transport.
self.
This makes the common form of "file:///C:/" into "file:///C:" which tickles the bug above, and would anyway not be accepted as valid by all applications. As far as I can see, the strip is entirely redundant as the first thing done inside is the call to split with the default argument `exclude_
So, the little things are easily fixed, but this is not a complete solution. There are at least two failing tests on windows (in bt.test_urlutils) from the addition of split_segment_
I'm pretty hesitant to change the required number of char to 4, but it may
be correct.
John /bugs.launchpad .net/bzr/ +bug/841322 /code.launchpad .net/~gz/ bzr/root_ drive_file_ url_841322/ +merge/ 74034 open_containing _from_transport ` they ascend until they reach a _win32_ extract_ drive_letter check: InvalidURL( url_base + path, /code.launchpad .net/~jelmer/ bzr/transport- segments/ +merge/ 71583> parameters functions. They __init_ _` which strips trailing parameters = urlutils. split_segment_ parameters( "/"))[1] trailing_ slash=True` which takes off the last slash without parameters_ raw inside
=:->
On Sep 5, 2011 1:33 AM, "Martin [gz]" <email address hidden> wrote:
> Martin [gz] has proposed merging lp:~gz/bzr/root_drive_file_url_841322
into lp:bzr.
>
> Requested reviews:
> bzr-core (bzr-core)
> Related bugs:
> Bug #841322 in Bazaar: "IndexError on windows from any operation that
opens a transport at root drive"
> https:/
>
> For more details, see:
> https:/
>
> Fixes massive breakage on windows from changes to path handling aimed at
smuggling extra information for colocated branch addressing into urls.
There's a fun set of interactions and a couple of very minor bugs that make
for some serious fallout.
>
> Lots of operations involve speculatively opening a location, and per
`BzrDir.
control directory or the root. Additionally, transports represents locations
as urls, and in the case of file system paths, as file: urls. Therefore on
windows, creating a transport at "file:///C:/" or such like is common. (As
an aside, the test suite is one place we generally avoid this, because we
want tests isolated they have a containing control directory).
>
> The simple bug is the urlutils.
>
> if len(path) < 3 or path[2] not in ':|' or path[3] != '/':
> raise errors.
> 'win32 file:/// paths need a drive letter')
>
> Which ensures the string is at least three characters long then looks at
the fourth character.
>
> This only gets exposed because of the set of changes landed in r6079:
> <https:/
>
> The problems come from the added split_segment_
aim to remove the extra bit from the end of the url, but use the normal url
split function, which requires a valid url an input. For most urls, adding a
comma and some more characters to the end just looks like a longer final
path segment, but there are some special cases that are rather different.
>
> The last complication is in `Transport.
forward slashes before passing on the url:
>
> self._segment_
> base.rstrip(
>
> This makes the common form of "file:///C:/" into "file:///C:" which
tickles the bug above, and would anyway not be accepted as valid by all
applications. As far as I can see, the strip is entirely redundant as the
first thing done inside is the call to split with the default argument
`exclude_
creating an invalid url.
>
>
> So, the little things are easily fixed, but this is not a complete
solution. There are at least two failing tests on windows (in
bt.test_urlutils) from the addition of split_segment_
the local_path_from_url implementations. That's from the issue above,
"file:///" can be treated as valid as a translation of the path \ but
"file:///,tip" can't be handled as a url. It's probably possible to hack
around that a...