From: Arcane Jill (arcanejill@ramonsky.com)
Date: Mon Jan 24 2005 - 02:18:03 CST
I, too, have also managed to create Windows filenames containing U+FFFF,
Windows filenames containing unpaired surrogates, etc.
I have also managed to store two files in the the same (Windows) directory, one
called "ss" and the other called "ß" (U+00DF). This violates the principle that
"ss" and "ß" are supposed to be equivalent in a case-insensitive system.
Windows was quite happy to handle those files after the event, including
copying them from place to place. Even the directory containing "ss" and "ß"
could be dragged from a FAT16 filesystem to an NTFS filesystem without
complaint
However - I *do not* believe that this behavior on the part of Windows is
correct. It is broken, and should be fixed. Filenames /should/ be made of
characters. Not opaque octets. Not opaque 16-bit words. This behaviour is
broken. Period.
Jill
-----Original Message-----
From: unicode-bounce@unicode.org [mailto:unicode-bounce@unicode.org]On Behalf
Of Lars Kristan
Sent: 22 January 2005 10:54
To: unicode@unicode.org
Subject: RE: Subject: Re: 32'nd bit & UTF-8
Then Windows should NOT allow creation of such filenames. But, hell, it surely
allows unpaired surrogates (Windows is still pretty much UCS-2). And it also
allows U+FFFF. Well, it looks like filenames on Windows are not really text,
they are binary data. Not that I believe that, but I've been told to process
UNIX filenames as binary data. Guess the same is then true for Windows
filenames. Nice.
Lars
This archive was generated by hypermail 2.1.5 : Mon Jan 24 2005 - 11:21:22 CST