Path: utzoo!attcan!utgpu!watserv1!watmath!att!pacbell.com!ucsd!usc!wuarchive!uunet!comp.vuw.ac.nz!cc-server4.massey.ac.nz!G.Eustace
From: G.Eustace@massey.ac.nz (Glen Eustace)
Newsgroups: comp.protocols.nfs
Subject: Re: Filenames with 0 length - An NFS bug or feature ?
Message-ID: <1990Dec20.195511.8242@massey.ac.nz>
Date: 20 Dec 90 19:55:11 GMT
References: <1990Dec20.035507.20698@massey.ac.nz> <1990Dec20.053123.24104@Think.COM>
Organization: Massey University, Palmerston North, New Zealand
Lines: 28
X-Reader: NETNEWS/PC Version 2.2

I would have thought that an NFS server implementation should have
performed some form of sanity checking on what a client passed it to
ensure that the requested operation was possible in the server
environment, or rather didn't lead to problems.  i.e. filenames were
acceptable, or if not a mapping was done.

We are running the 'aufs' part of CAP to provide a network file
system for MACIntosh clients.  We were bitten by the '/' in the name
problem as well.  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.  The
cure, if my memory serves me correctly, for this was to ensure that
the '/' was included in the set of characters that were mapped to
':xxx' where xxx is the octal character code.  This mapping was
necessary for other characters as MAC users seem to love having
'graphic' characters in filenames.

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.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Glen Eustace, Software Manager, Computer Centre, Massey University,
Palmerston North, New Zealand.        EMail: G.Eustace@massey.ac.nz
Phone: +64 63 69099 x7440, Fax: +64 63 505 607,    Timezone: GMT-12