Slashes in file names

[Barry Margolin]

It's quite obvious to anyone who has implemented NFS for non-Unix systems
that NFS isn't quite as OS-independent as it was intended to be.  The most
obvious problem is that symbolic link targets are returned to the client as
text, and the client must parse it; Unix clients expect to be able to parse
them as Unix pathnames, so non-Unix servers must translate their symbolic
links to Unix syntax if they want Unix clients to be able to use them, and
non-Unix clients must be able to parse Unix pathnames in order 

In article <25881 at adm.brl.mil> ssds!tims at uunet.uu.net (Tim Sesow (SSDS Rocky Mntn)) writes:
[Regarding the fact that the NFS spec doesn't prohibit slashes in file
names, therefore it's a Unix bug that such files are not usable:]
>I would like to hear suggestions for changes to the NFS spec.
>to solve this problem, since I can't think up any that work in
>the long run.

>Just to forestall some discussion:
>1. Telling the Gatorbox to not allow slashes doesn't work.  I
>see too many files with names like "Expense Report 12/14/90".
>2. Translating the slash just moves the problem to another 
>character.
>3. Adding a directory delimiter to the NFS spec doesn't fit with
>the way NFS works for directories.

The NFS 3.0 specification, and the NeFS proposal that followed it, include
ways for a client to query the server to find out which characters aren't
allowed in file names.  A Unix server would disallow "/", a Macintosh
server would disallow ":", a Multics or Symbolics server would disallow
">", etc.  It's up to the client how it deals with such limitations, but I
expect it would simply translate the invalid characters to other
characters.
--
Barry Margolin, Thinking Machines Corp.

barmar at think.com
{uunet,harvard}!think!barmar