Re: [Jfs-discussion] Problems with charset.
Brought to you by:
blaschke-oss,
shaggyk
From: John G. <jgo...@co...> - 2004-06-28 19:25:00
|
On Mon, Jun 28, 2004 at 10:57:25AM -0500, Dave Kleikamp wrote: > On Sun, 2004-06-27 at 08:04, Antonio A. wrote: > > This is a FS problem since I had a previous version of the dictionary > > that I installed without problems. > > > > Doing a dmesg I get this > > > > jfs_strtoUCS: char2uni returned -22. > > charset = utf8, char = 0xea > > iocharset=utf8 tells jfs that the pathnames are utf-8, but that is not > the character set being used. 0xea is ê in iso8859-1. It could be a > valid byte of a utf-8 character, but the next two bytes would have to > have the high order bit set, and I assume they don't. (I'm sure they > are 's' and '.'.) I am confused about all of this. Why should the filesystem care? With every other FS, it just stores the stream of bytes that make up the filename. Why is JFS any different? On the 2.4.26 system I just installed, lots of filenames came back with '?' characters in them. I finally had to mount it with charset=utf8. At least that way, files can be deleted. I had reported the same bug in 2.6, and it appears to have been fixed there. Why not in 2.4 also? > > I have the iocharset=utf8 mount option set in fstab. > > Are you sure your system is configured in a utf-8 locale? (What is > $LANG?) That is a fallacy. There is no reason to assume that everything on the system uses the same locale setting. For instance: * Some users may log in from Unicode-capable terminals, and thus prefer to use UTF-8. Others may use a Latin-1 terminal. * The machine may act as a file server, serving files to machines that are individually configured with different locales. (Heck, they may even be physically located in different locales!) * LANG could be individually set per-user or even per-process for a variety of reasons. I don't see why JFS forces this system-wide choice. -- John |