From owner-freebsd-arch Wed Feb 28 22:45:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from areilly.bpc-users.org (CPE-144-132-234-126.nsw.bigpond.net.au [144.132.234.126]) by hub.freebsd.org (Postfix) with SMTP id 8DA3537B71A for ; Wed, 28 Feb 2001 22:45:14 -0800 (PST) (envelope-from areilly@bigpond.net.au) Received: (qmail 65096 invoked by uid 1000); 1 Mar 2001 06:45:13 -0000 From: "Andrew Reilly" Date: Thu, 1 Mar 2001 17:45:13 +1100 To: "Michael C . Wu" Cc: Terry Lambert , Jonathan Graehl , freebsd-Arch , i18n@FreeBSD.ORG Subject: Re: Unicode, command line options, and configuration files, oh my! Message-ID: <20010301174513.A65013@gurney.reilly.home> References: <200103010541.WAA17385@usr05.primenet.com> <20010301000207.C4359@peorth.iteration.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010301000207.C4359@peorth.iteration.net>; from keichii@iteration.net on Thu, Mar 01, 2001 at 12:02:07AM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Mar 01, 2001 at 12:02:07AM -0600, Michael C . Wu wrote: > Terry wrote: > | In general, this means that for Unicode data stored for > | directory entries would require that a directory entry > | block would have to be 512b, whereas for UTF-8, we are > | talking 2048b (2k). It would still have to be larger than 512b using a 16-bit encoding, wouldn't it? > | If the same approach is used as the current UFS code uses, > | then these operations will need to be directory entry block > | atomic. > > In short, we can save the file name that the user sees > with the file data. The filesystem and the kernel sees > some other naming scheme determined by the FS/kernel. How do you propose to do that and still maintain Unix inode/link semantics? There isn't (necessarily) only one file name that the user sees, but there _is_ only one lump of file data. > | On top of that, we have Microsoft and Java interoperability to > | consider, distasteful as that may be to some. > > M$ has a pretty good implementation here. > Java I18N sucks really bad. Could you give a quick description of why one of these is good and the other bad, for the bennefit of someone who knows neither? -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message