Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.

Lars Noschinski:

Using no encoding for filenames was the obvious (and I would argue) 
correct choice. Unix filenames are specified to be a sequence of bytes, 
excluding '/' and '\0'.

I know the Unix way of thinking lends itself to such a design. This is one 
of the few cases where I personally think Unix has got it wrong, and Windows 
(NT) has got it right. But then again, Unix' design pre-dates the locale 
issue by quite some time, so it is not difficult to see where it comes from.

Changing the filename (on checkout), so that the user sees an Ü regardless 
of his or her locale (instead of an \0xDC, which only resolves to an Ü on 
latin-1) would be an absolutely broken concept here.

Why would it? It is my view as a user on my files that define how file names 
are looked upon. If I have three machines, one Linux box using a iso8859-1 
locale, an OS X box (where, I would believe, file APIs use UTF-8, someone 
please correct me if I'm wrong), and a Windows box (which uses UTF-16 on the 
file system layer, but does provide compatibility functions that use char 
pointers), and create a file on each of these called "Ü.txt" (which would be 
the sequence "DC 2E 74 78 74" on the Linux box, "C3 9C 2E 74 78 74" (or 
probably something else since I believe OS X decomposes the string) on the 
OS X box and "00DC 002E 0074 0078 0074" on the Windows box, I see these 
three file names as equal.

If I would create a Git repo on each of the three machines and put the file 
name in it, and then clone that on one of the other machines. *I* would 
assume that the file names were converted to fit the host operating system.

IMHO having encoding specific open functions is begging for problems.

Indeed. That's why I like Windows' wchar_t APIs, and dislike Unix' and 
Linux' char APIs that, in some ways, depend on the user locale.

-- 
\\// Peter - http://www.softwolves.pp.se/