Messages in this thread | | | Subject | JFS default behavior (was: UTF-8 in file systems? xfs/extfs/etc.) | From | Dave Kleikamp <> | Date | Wed, 11 Feb 2004 10:35:10 -0600 |
| |
On Wed, 2004-02-11 at 00:39, Tim Connors wrote: > I submitted a bug to the jfs people, because jfs incorrectly returns > -EINVAL (this isn't even documented in man pages as a valid return > from open()) from an open() on a filename with UTF-8 in it. > > See http://www-124.ibm.com/developerworks/bugs/?func=detailbug&bug_id=3838&group_id=35 > and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229308 > > This was triggered just by upgrading the console-utils package in > debian (the problem existed all along, except that when I first made > the filesystem a jfs one, I reinstalled from backups, rather than > reinstalling debian from scratch)
Yeah, JFS has poor default behavior based on CONFIG_NLS_DEFAULT. I attempted to explain why it works that way in the first bug listed above if anyone is curious.
I think the right thing for JFS to do is to change the default behavior to simply store the bytes as they are seen, and to only do charset conversion when the iocharset mount option is explicitly set. This may impact some current users, but they will be able to get the old behavior by setting iocharset to whatever CONFIG_NLS_DEFAULT is set to in the running kernel.
I intend to make this change soon if there are no objections.
Thanks, Shaggy -- David Kleikamp IBM Linux Technology Center
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |