Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.unix.wizards Subject: Re: Slashes in file names Message-ID: <1991Feb7.221243.24776@Think.COM> Date: 7 Feb 91 22:12:43 GMT References: <25881@adm.brl.mil> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 35 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@adm.brl.mil> ssds!tims@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@think.com {uunet,harvard}!think!barmar