Merge lp:~mbp/bzr/224373-2.2-ftp-response into lp:bzr/2.2
| Status: | Merged |
|---|---|
| Approved by: | John A Meinel on 2010-08-16 |
| Approved revision: | 5077 |
| Merged at revision: | 5078 |
| Proposed branch: | lp:~mbp/bzr/224373-2.2-ftp-response |
| Merge into: | lp:bzr/2.2 |
| Diff against target: |
36 lines (+14/-1) 2 files modified
NEWS (+3/-0) bzrlib/transport/ftp/__init__.py (+11/-1) |
| To merge this branch: | bzr merge lp:~mbp/bzr/224373-2.2-ftp-response |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| John A Meinel | Approve on 2010-08-16 | ||
| Martin Packman (community) | 2010-08-16 | Approve on 2010-08-16 | |
|
Review via email:
|
|||
Commit Message
cope with ftp servers giving 250 reply for mkd (bug 224373)
Description of the Change
Here's a workaround for MS FTP server's habit of returning '250' for successful mkd calls.
This is done 'blind' without a test and without testing it against a Microsoft ftp server, just based on the tracebacks and interactively creating an error that looks like them. If someone could actually test this, that would be good.
| John A Meinel (jameinel) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin Pool wrote:
> Martin Pool has proposed merging lp:~mbp/bzr/224373-2.2-ftp-response into lp:bzr/2.2.
>
> Requested reviews:
> bzr-core (bzr-core)
> Related bugs:
> #224373 Bzr ftp support does not handle 250 response from Windows 2003 server for mkdir
> https:/
>
>
> Here's a workaround for MS FTP server's habit of returning '250' for successful mkd calls.
>
> This is done 'blind' without a test and without testing it against a Microsoft ftp server, just based on the tracebacks and interactively creating an error that looks like them. If someone could actually test this, that would be good.
Seems reasonable to me. Obviously I'd rather this was tested by someone
actually using it.
I'd also like to ask why you targeted 2.2, but not 2.0 or 2.1? Anyway,
in general:
merge: approve
Though if you know someone that can actually test it, it would be nice
to wait to land until then. (As *I* don't know anyone, and can't do it
myself, I wouldn't block on this.)
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkx
U6oAoJ1rocNHchw
=Da49
-----END PGP SIGNATURE-----
| Martin Pool (mbp) wrote : | # |
I had mixed feelings about whether something that's a workaround for a
bug elsewhere, and not automatically tested, ought to go into stable
series. 2.2 was kind of a compromise. On the whole I might put it
only into 2.3. One of the affected users offered me access to an ftp
server to at least test it interactively.
--
Martin
| Martin Pool (mbp) wrote : | # |
@mgz good catch re setmode; I would presume it probably will fail but we should probably set it anyhow.
- 5078. By Martin Pool on 2010-08-17
-
Narrower try/except scope for ftp reply 250 from mkd
| Martin Pool (mbp) wrote : | # |
sent to pqm by email

Looked at this bug yesterday as well and this change is the same conclusion I'd drawn. Are you considering _setmode redundant as it's an win ftp server bug, or should that be called on this path as well?
Had looked at the ftp tests as well and bar subclassing both the medusa and pyftpdlib paths it didn't seem like this 'd be properly testable so just the fix is okay I think.