Slashes in file names

Steve Summit scs at adam.mit.edu
Thu Feb 14 18:05:12 AEST 1991


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; <errno.h> 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 at adam.mit.edu



More information about the Comp.unix.internals mailing list