Comment 9 for bug 77657
Revision history for this message
| Robert Collins (lifeless) wrote Re: [Bug 77657] Re: bzr add fails on a non-utf8 filename in an utf8 locale | #9 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
On Wed, 2008-04-23 at 07:37 +0000, codeslinger wrote:
> yet another of the file name bugs....
>
> please see the discussion in Bug #135320
>
> also if you will take a look at this table http://
> you will see that on windows there are many valid extended characters.
>
> Wouldn't it be much better to not mangle the names at all? just escape
> them and preserve their literal values.
>
> It's all very fine and well for someone who is a unix only person to
> decree that he only cares about what will work for him. But what about
> the rest of us poor blokes who have to deal with file names that we have
> no control over?
I think you have some confusion present. The different bugs are not all
dups; they are indeed raising the same exception but in different places
and for different reasons.
Using unicode lets us take a file with a given name from unix to OS X,
and then to windows, even though they all have different encodings for
the same file name. bzr is not mangling file names, its converting from
a byte stream to unicode.
For a file name to be usable on a file system, it needs to be in some
specific encoding. Some file system interfaces ignore encodings. Others,
like mac OS X, force everything to unicode.
-Rob
--
GPG key available at: <http://