Re: Serving UTF-8 via NFS to Mac OS X

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> When serving files with UTF-8 file names to a Mac OS X machine via
>> NFS, I often get into trouble since the client can display the file
>> names, but can't access the files.

>> I understand that this is caused by Mac OS X expecting its file
>> names to be in UTF-8 decomposed form while NetBSD by default has
>> precomposed (or the other way round :) ).

I'd suspect part of it is that most systems don't have character
strings for file names, but rather octet strings.  Traditional Unix
certainly does, as indeed it must because there is no provision for
indicating encoding with the octet strings passed around by the
filesystem calls.  While I haven't kept totally up to date on recent
mutations of NFS, the NFS I knew was similar: the pathname components
passed between client and server had no encodings attached to them and
thus had to be octet strings rather than character strings.  (For
example, does the octet string 0x41 0xc4 0xa7 mean "uppercase A,
lowercase h-bar", or does it mean "uppercase A, uppercase A with dots,
section sign", or does it mean "uppsercase A, uppercase delta, section
sign", or what?  With the Unix filesystem inteface, there's no way to
draw that distinction.)

If OSX expects to send one octet string to the server and then get a
different string back (because of, eg, composition changes), it is
fundamentally broken.  Or is this about files created by non-OSX
clients, or on the server underneath the NFS server, and then accessed
from OSX?  In that case, yes, I blame OSX, for thinking filenames are
character strings when they aren't.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B