Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!spool.mu.edu!uunet!world!bzs From: bzs@world.std.com (Barry Shein) Newsgroups: comp.unix.wizards Subject: Re: Slashes in file names Message-ID: Date: 7 Feb 91 23:08:12 GMT References: <25881@adm.brl.mil> Sender: bzs@world.std.com (Barry Shein) Organization: The World Lines: 32 In-Reply-To: ssds!tims@uunet.uu.net's message of 7 Feb 91 14:58:03 GMT >I am fairly sure that the NFS spec does not contain any limitations >on the file names, therefore a slash is allowed. Given that, >it seems that any system that is sold as a file server should >have the utilities (other than just "dd") to handle the >system administration of these files. > >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. The pre-emptive solution is fairly obvious. Many NFS servers or clients do various magic things to accommodate foreign file systems (such as for DOS.) Unix NFS servers just need the same kind of thing. File names could be scanned for "funny characters" on create requests and some convention could be used to indicate that it is to be translated back to slash on read-out by a client of the same sort. Or it could go in the client (I think this sort of thing is often done in the client, tho one can argue for doing this one in the server for self-defense reasons.) So, for example, "Expense Report 2/30/91" could be stored on Unix as "Expense Report 2##30##91" or some such thing, and the appropriate warning about file name length limitations (slashes count as two characters) could be issued. Whatever. They'd then be read back and the slashes re-inserted, and everyone lives happily ever after. -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD