Re: vfat: Broken case-insensitive support for UTF-8

[Theodore Y. Ts'o]

On Mon, Jan 20, 2020 at 01:04:42PM +0900, OGAWA Hirofumi wrote:
> 
> To be perfect, the table would have to emulate what Windows use. It can
> be unicode standard, or something other. And other fs can use different
> what Windows use.

The big question is *which* version of Windows.  vfat has been in use
for over two decades, and vfat predates Window starting to use Unicode
in 2001.  Before that, vfat would have been using whatever code page
its local Windows installation was set to sue; and I'm not sure if
there was space in the FAT headers to indicate the codepage in use.

It would be entertaining for someone with ancient versions of Windows
9x to create some floppy images using codepage 437 and 450, and then
see what a modern Windows system does with those VFAT images --- would
it break horibbly when it tries to interpret them as UTF-16?  Or would
it figure it out?  And if so, how?  Inquiring minds want to know....

Bonus points if the lack of forwards compatibility causes older
versions of Windows to Blue Screen.  :-)

      	     	   	  		   	- Ted

P.S.  And of course, then there's the question of how does older
versions of Windows handle versions of Unicode which postdate the
release date of that particular version of Windows?  After all,
Unicode adds new code points with potential revisions to the case
folding table every 6-12 months.  (The most recent version of Unicode
was released in in April 2019 to accomodate the new Japanese kanji
character "Rei" for the current era name with the elevation of the new
current reigning emperor of Japan.)