Path: utzoo!mnetor!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!oliveb!sun!gorodish!guy From: guy@gorodish.Sun.COM (Guy Harris) Newsgroups: comp.unix.wizards Subject: Re: filenames with the high bit set. Message-ID: <49211@sun.uucp> Date: 12 Apr 88 17:43:13 GMT References: <8120010@eecs.nwu.edu> <48993@sun.uucp> <4540@bloom-beacon.MIT.EDU> <6173@elroy.Jpl.Nasa.Gov> Sender: news@sun.uucp Lines: 34 > < 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.