Kamil Szot wrote:
> 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,
If the actual server is agnostic, then it means that Bazaar can chose
what encoding it wants to use.
>
> 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).
Except it uses the local encoding, and fancy_rename is being run on a
remote location. Where it matters what the *remote* encoding is.
# Rename the file out of the way, but keep track if it didn't exist
I *believe* that fancy_rename is being called on URL fragments, which
should *not* be Unicode strings. (In bzr, paths are Unicode, urls are
url-escaped-utf8-encoded 7-bit ascii strings.)
>
> 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.
You can get the latest version in the bzr ppa, or see this blog post: http://code.mumak.net/
>
> 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.
>
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kamil Szot wrote: bazaar. launchpad. net/~vila/ bzr/472161- ftp-utf8/ revision/ 4936 I
> By examining the changes you made
> http://
> 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,
If the actual server is agnostic, then it means that Bazaar can chose
what encoding it wants to use.
>
> 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).
Except it uses the local encoding, and fancy_rename is being run on a
remote location. Where it matters what the *remote* encoding is.
However, I think a key change would actually be:
=== modified file 'bzrlib/osutils.py' basename( new) dirname( new) s.%.9f. %d.%s' % (base, time.time(), os.getpid(),
- --- bzrlib/osutils.py 2009-12-23 00:15:34 +0000
+++ bzrlib/osutils.py 2010-01-07 17:00:45 +0000
@@ -208,7 +208,7 @@
# sftp rename doesn't allow overwriting, so play tricks:
base = os.path.
dirname = os.path.
- - tmp_name = u'tmp.%
rand_chars(10))
+ tmp_name = 'tmp.%s.%.9f.%d.%s' % (base, time.time(), os.getpid(),
rand_chars(10))
tmp_name = pathjoin(dirname, tmp_name)
# Rename the file out of the way, but keep track if it didn't exist
I *believe* that fancy_rename is being called on URL fragments, which utf8-encoded 7-bit ascii strings.)
should *not* be Unicode strings. (In bzr, paths are Unicode, urls are
url-escaped-
> coding( ) like complained about tarekziade. wordpress. com/2008/ 01/08/syssetdef aultencoding-
> 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.setdefaulten
> here http://
> 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.
You can get the latest version in the bzr ppa, or see this blog post: code.mumak. net/
http://
>
> 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.
>
John enigmail. mozdev. org/
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkt GE54ACgkQJdeBCY SNAANv+ wCgmrcUqpC3yc3N kUTDN2NRiteh waNXq+2RFya94Kl GG
Vc0AoKJuWOEtGIV
=mTwE
-----END PGP SIGNATURE-----