Comment 1 for bug 77657

On Wed, Jan 03, 2007 at 10:49:39AM +0000, Lars Wirzenius wrote:
> On ti, 2007-01-02 at 17:30 -0600, John Arbash Meinel wrote:
> > This isn't strictly a bug, it probably shouldn't be giving a traceback,
> > but rather a more helpful error. Basically, we disallow '\' as a
> > character in filenames.
>
> Hm. This is quite surprising to me as a Unix user. It does not seem to
> be documented on the manual page.
>
> Given that \ (and * and ? and [ and ] and : and various other
> characters) and non-Unicode strings actually exist in program source
> file names, I'd be rather happier if bzr would allow them to be used.
> It's not a top priority for me, but for completeness the tool should, in
> my opinion, allow them.
>
> > It isn't the only one (we only support Unicode
> > names, so there are a few byte sequences that could probably be
> > considered illegal).
>
> The source tree has some non-Unicode, non-ASCII filenames, and those
> resulted in crashes (stack traces and termination of process). I removed
> them to be able to complete the test. I'll do the same with filenames
> containing \ as well. Are there any other characters I should be wary of
> as well?

The non-unicode non-ascii files in a utf8 locale are problematic during
add, os.listdir() is fine, but the sorted() wrapping that call blows up.

Robert thought it wasn't sane to deal with a filename not decodable in
the user encoding, where I just wanted that exact byte sequence checked
in. At the very least that means the filename will be unintelligible on
windows, macosx, or in any other encodings. Worse, it might not even
check out at all. This is a general problem we also encounter with the
illegal characters for fat, upper/lower case clashes or files called
con.txt on windows.

Wouter van Heyst