Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.protocols.nfs
Subject: Re: Filenames with 0 length - An NFS bug or feature ?
Message-ID: <5020@auspex.auspex.com>
Date: 4 Jan 91 01:02:15 GMT
References: <1990Dec20.035507.20698@massey.ac.nz> <1990Dec20.053123.24104@Think.COM> <1990Dec20.195511.8242@massey.ac.nz>
Organization: Auspex Systems, Santa Clara
Lines: 31

>Unix was quite happy with a '/' in the name.  It was the utilities that
>really had problems as they, rightly, assumed that the '/' was a
>directory seperator and treated it as such.

Well:

1) "UNIX" includes the utilities; it's not just the kernel.

2) In most UNIX implementations, even the kernel isn't "happy" with a
   '/' in the name, in that the code that implements "open()", "stat()",
   etc., etc., etc. assumes that '/' is a directory separator and treats
   it as such, so there's not much any utility that doesn't directly
   access the raw disk can do about it.

The problem is that the NFS server code typically goes around the code
in the kernel that assumes that '/' is a directory separator; the file
system implementation doesn't treat "/" specially in systems with
SunOSish vnode implementations, as it's handed one component at a time.

>Bearing in mind the above example, surely it would be sensible to
>place the onus of ensuring a sane, robust filesystem should be the
>responsibility of the server side of NFS as it is it would appear
>that any irregularity on the part of a client can stuff things well
>and truly.

Yup.  Our NFS server implementation slaps the client's wrist (with
EINVAL, at least if it's a UNIX client) if the client hands it a
component name containing a "/"; I think the SunOS 4.1 server
implementation may do so as well.  Ours also rejects zero-length file
names (again, with EINVAL), and I think the 4.1 server implementation
does the same.