Re: JFS default behavior (was: UTF-8 in file systems? xfs/extfs/etc.)

[Robin Rosenberg <robin.rosenberg.lists@dewire.com>]

On Friday 13 February 2004 07.59, Chris Siebenmann wrote:
> You write:
> | Oh, I wasn't thinking of fixing *every* application out there, but
> | making the kernel api's convert between the user locale and the file
> | system locale, thus restricting the problems to places that can be
> | fixed.
> 
>  Why should the kernel have any idea about locales, or care? (We've just
> had an illustration, in this very thread, about why bits of the kernel
> caring about locales is dangerous.)
We have also explained why it's a problem and why "something" should care. 
The problem is clear, the solution is less clear. Some file systems already try to 
to handle the issue because the fs itself define the character set. That's the
argument for solving the issue with other file systems the same way. It's also only 
the fs media that can reliably know this since media are movable these days.

>  Making the kernel convert between character sets also requires as a
> corollary that the kernel know about all of the character sets, which is
> both dangerous and liable to expand one's kernel impressively.
That's NLS support, which is already there. Conceivably this could be
a compile-time option for the file systems that due legacy do not state
what character set/encoding is to be used so the system could be tuned
for use in a homogeneous environment w.r.t locale.

>  Declaring that the kernel operates in a fixed locale amounts to
> declaring that it will reject certain byte sequences for filenames
> because it doesn't like how they smell, without clear technical need
> for it. People generally object to their kernel restricting them for
> such reasons.

The needs are not "technical", they are "user" needs. (I hear them laughing
in Redmond).

-- robin