Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!midway!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.wizards
Subject: Re: (was slashes, now NFS devices)
Message-ID: <1991Feb25.194725.15597@chinet.chi.il.us>
Date: 25 Feb 91 19:47:25 GMT
References: <14363@ulysses.att.com> <1991Feb24.041451.13769@chinet.chi.il.us> <14368@ulysses.att.com>
Organization: Chinet - Chicago Public Access UNIX
Lines: 43

In article <14368@ulysses.att.com> ekrell@ulysses.att.com (Eduardo Krell) writes:

>>Unless you want to run diskless on the local machine, in which case
>>the local machine needs somewhere to put the names of its own devices.

>yes, I'm aware of this. But it seems like a poor excuse to do it the other
>way. I agree that there should be a way of telling the server to interpret
>special files remotely or locally. How about symbolic links? Should absolute
>symbolic links be always interpreted on the client? the server? why?

Why shouldn't you have a choice with the default being the machine that
creates the symlink?  Likewise, why shouldn't you be able to mark any
file as "local-only" or "remote-only" and make it invisible or at least
mode 000 when accessed the wrong way?  (Ideally, "local-only" would apply
to the machine creating the file, not the one storing it, since this could
allow multiple files of the same name to be stored on a common server so
you could do things like sharing /etc without symlinking everything).

It's about time to take the "network-is-the-computer" to the logical extreme
and rewrite the local processing as though it were happening over a
packet network using appropriate device and file system semantics.  Then the
difference between local and remote forms of access can really go away.

Until then, we are stuck with lots of warts from making remote access look
like the local form for backwards compatibility.

Example of RFS-induced problem:
  We have many users running PC's with AT&T's DOS server software connecting
  them to a unix machine.  On this machine we have some RFS links to some
  other machines.  On the surface it all works pretty well - the DOS users
  can access files through the RFS mounts.  *However*, when an RFS mount
  is broken, all processes that have open files there are killed.  It
  happens that one DOS Server process serves several users, so if one
  user happened to leave a file open that happened to be on the RFS mounted
  directory when that host was disconnected, suddenly we would have 6 dos
  users (or all of them if the user was being served by the parent process)
  with broken links.  This was great fun to debug, and it's hard to place
  the blame on either RFS or the DOS Server, since both were doing what they
  were designed to do.  It just points out one of the problems of trying
  to hide the fact that you are networking. 

Les Mikesell
  les@chinet.chi.il.us


Brought to you by Super Global Mega Corp .com