question about Latin1Environment>>fileNameConverterClass and 3.9

I noticed that we have
Latin1Environment>>fileNameConverterClass
        ^Latin1TextConverter

However the mac vm usually by default runs in macroman file name  
logic for historical reasons, although some
products switch to UTF-8.

However when we get directory entires, they are mangled by  
convertFromSystemName which applies
a Latin1TextConverter to a macroman file name, or perhaps to a UTF-8  
file name.

That results in confused results in the file browser, or perhaps  
things like StandardFileStream>>modificationTime failing
because the filename in macroman or utf8 format can't be found in the  
directory entries for the swizzled incorrect conversion.

I'll note you can't run in Latin1 path name mode in the mac VM  
because there are many many characters you can enter in UTF8
that will not convert to Latin1 via os-x system calls.

So should this be a Latin1TextConverter on windows, and UTf8 or  
MacRoman elsewhere?
Anyone have a proposed solution?

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

  John,

> I'll note you can't run in Latin1 path name mode in the mac VM  
> because there are many many characters you can enter in UTF8
> that will not convert to Latin1 via os-x system calls.
>
> So should this be a Latin1TextConverter on windows, and UTf8 or  
> MacRoman elsewhere?
> Anyone have a proposed solution?

  Take a look at JapaneseEnvironment class>>fileNameConverterClass
and JapaneseEnvironment class>>systemConverterClass.  You'll need
similar thing for Latin1Environment.

  For future implementation, the locale mechanism should be used in a
better way to avoid this switching...

-- Yoshiki