Xref: utzoo comp.unix.wizards:24107 comp.unix.internals:2050 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-picayune.mit.edu!news From: scs@adam.mit.edu (Steve Summit) Newsgroups: comp.unix.wizards,comp.unix.internals Subject: Re: Slashes in file names Message-ID: <1991Feb14.070512.24190@athena.mit.edu> Date: 14 Feb 91 07:05:12 GMT Sender: news@athena.mit.edu (News system) Reply-To: scs@adam.mit.edu Organization: Thermal Technologies, Inc. Lines: 38 I begin to understand why people have such passionately awful things to say about NFS. As far as I'm concerned, if the NFS server code can create an illegal file (where "illegal" is defined by the host on which the server is running), then that's a bug in the NFS server, period. If the protocol doesn't include an error return of "I can't create a file of that name" (not surprising; doesn't define that specific error either, although it probably should), then it should just say something halfway like "no such file or directory." If the client can help out by trying not to ask for illegal files in the first place, that's fine; but in the final analysis the server has got to protect itself. Having the client not ask for illegal files is never going to work perfectly, anyway: even if a negotiation is defined by which the client can learn which characters are illegal, some operating system somewhere is going to have rules that can't be encoded that simply. Has anyone ever considered modifying namei so that it essentially checks to see if the current path character matches a target filename character *before* checking to see if the current path character is a '/'? That would make the filesystem robust against inadvertent /'s in filenames, because unlink("a/b/c") would in fact unlink a file called "b/c" in directory "a", if one somehow existed. (To be sure, there would be idiosyncrasies associated with such an algorithm. In the above example, if directory "a" also contained a subdirectory "b" as well as a file "b/c" the behavior would depend on which came first, or something. Still, it might be a nice escape hatch. Note that by only attempting to match existing files in this way, it would still never create a filename with a slash.) Steve Summit scs@adam.mit.edu