Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!sol.ctr.columbia.edu!emory!ra!Ra.MsState.Edu!fwp1 From: fwp1@CC.MsState.Edu (Frank Peters) Newsgroups: comp.unix.wizards Subject: Re: (was slashes, now NFS devices) Message-ID: Date: 23 Feb 91 22:02:40 GMT References: <15236@smoke.brl.mil> <123382@uunet.UU.NET> <1991Feb22.141910.17013@decuac.dec.com> <14363@ulysses.att.com> Sender: usenet@ra.MsState.Edu Organization: Computing Center, Mississippi State University Lines: 52 Nntp-Posting-Host: jester.cc.msstate.edu In-reply-to: ekrell@ulysses.att.com's message of 23 Feb 91 20:30:48 GMT In article <14363@ulysses.att.com> ekrell@ulysses.att.com (Eduardo Krell) writes: > In article bzs@world.std.com (Barry Shein) writes: > [about NFS special files] >>Obviously they should be interpreted >>relative to the local host only. > Not so obvious to me. After all, the server is probably the only machine > which can interpret the meaning of that special file in a sensible way. > By forcing a local interpretation of special files, you lose the ability > to access remote devices. > If you can access remote files, why can't you access remote devices using > the same mechanism? Under RFS, special files are interpreted by the server. You ignore (or aren't aware of) two important differences between RFS and NFS that make this impractical. 1. NFS is designed to be operating system independant while RFS assumes UNIX on both ends of the connection. The concept of a file system entry that points to a device by magic major and minor codes is very OS specific. While that concept is by no means unique to UNIX it is far from universal and implemented differently wherever it is found. 2. This is probably most important. NFS is stateless. Whether this statelessnes is a good thing or not is another debate. But it means that I can open a file on a remote host via NFS and be in the middle of updating it when the server reboots and when the server comes back up the operation will continue. Mapping this functionality to tape devices would require the server to assure that the tape is positioned to EXACTLY the position it was at when the reboot occured so that the remote tar can continue unabated. Even if this were practical it would be a royal pain. No, I think special files must be treated like any binary data. If I mount my sparc executables on a MIPS box those files are meaningless data. If I want to right a sparc simulator I should be able to access those files as executables for my simulator. I shouldn't and can't execute that sparc binary and make it run on the server. In the same way, a special file mounted on a non UNIX box should be meaningless data. If I choose to write a UNIX device file interface emulator for VMS or DOS I should be able to pass it the special file data for local interpretation. I shouldn't be able to access those files and have it affect the remote server. Frank -- Frank Peters Internet: fwp1@CC.MsState.Edu Bitnet: FWP1@MsState Phone: (601)325-2942 FAX: (601)325-8921 Brought to you by Super Global Mega Corp .com