filenames with the high bit set.

[Guy Harris]

> < That's obviously a bug, not a feature.  You can't create files containing "/"
> < by using the official UNIX mechanisms for creating files.
> 
> What if the NFS server is not a *Unix* machine?

Then if the native file system supports "/" in file names, the server should
allow them.  UNIX clients will obviously not be able to get at such files,
unless the client code does some sort of file-name mapping, just as MS-DOS
clients have to do some sort of mapping to handle file names such as
"FoObAr_and_a_bunch_of_other_stuff.4.65.13", and VMS clients would presumably
have to do some sort of mapping to handle file names such as "[[[[]]]]..dir",
etc..

> What if the client is not a Unix machine?

If the client is not a UNIX machine, and the server is, the client just has to
lose or do file-name mapping if it wants to handle file names containing
slashes.  If the client is not a UNIX machine, and the server isn't, and the
server's native file system can handle "/" in file names, you win.  If it's not
a UNIX system, but it can't handle "/" in file names, you lose.

> There is no NFS error to indicate an illegal file name character!

Well, presumably the NFS servers written for VMS have stolen some other error
code to use to complain about attempts to e.g. create files with names
containing characters not considered kosher in VMS (I don't remember whether
ODS-2 directories contain file names in ASCII or RADIX-50; if the latter, there
are characters that are not only non-kosher but not representable).  Also,
if 4.3BSD servers reject file names containing characters with the 8th bit set,
they also have to choose some error code, since the error that the file system
code returns for this is EINVAL, which has no direct NFS equivalent.

It is not ideal that a server has to steal another error code for this.  Future
versions of the NFS protocol should probably include such an error code.