Comment 11 for bug 472161

By examining the changes you made http://bazaar.launchpad.net/~vila/bzr/472161-ftp-utf8/revision/4936 I doubt this goes anywhere near fixing my trouble.

FTP servers are usually encoding agnostic. They treat file names as built of 8-bit characters without any specific encoding. They don't support any encoding explicitly,

Please take a look at my changes. They should fix the problem even if your system uses some other encoding for filenames (for example iso-8859-2).

The root of my problem seems to come from the fact that python os.path functions appear not to be aware of the fact that OS might use different encodings for file names. They just return string and if it is implicitly converted to unicode at some point then the 'ascii' encoding is used. I wonder how the core of bzr deals with this. Some people get around such bugs by setting default encoding for unicode<->string conversions by calling os.setdefaultencoding() like complained about here http://tarekziade.wordpress.com/2008/01/08/syssetdefaultencoding-is-evil/

I have not made merge proposal yet because I wanted to hear your opinion first and test if it breaks testsuite for myself.

I think I sorted out the problems with branch divergence by merging and doing empty commit. I'll remember the --overwrite trick for later use in similar cases.

bzr selftest reports that I have too old version of python-testtools i my ubuntu, I'll try to fix that but it might take me a moment.

I'm using bazaar with python 2.6.4, I'll try to install medusa or pyftpdlib, run the tests the way you described and report my findings.