[51] in DCNS Development
Re: Filesystem Reorganization for release 7.3
daemon@ATHENA.MIT.EDU (mhpower@ATHENA.MIT.EDU)
Wed Jul 3 19:27:34 1991
From: mhpower@ATHENA.MIT.EDU
To: Raeburn@MIT.EDU
Cc: akajerry@ATHENA.MIT.EDU
Cc: mar@MIT.EDU, developers@MIT.EDU, release-73@MIT.EDU, acmg@MIT.EDU
Cc: bug-sipb@ATHENA.MIT.EDU
In-Reply-To: Ken Raeburn's message of Wed, 3 Jul 91 16:56:13 -0400
Date: Wed, 03 Jul 91 19:24:43 EDT
Also, there is one currently existing directory we haven't mentioned
yet, /usr/sipb. My vote is that we nuke it, keeping the appropriate
compatability link on the VAX and RT.
I disagree. That software uses "/usr/sipb" internally, for reasons
that have been discussed several times. If you remove this link, you
will break the software, unless the mount point itself gets changed.
I don't think changing the sipb locker mountpoint to /usr/sipb would
be a satisfactory solution. On a number of machines, including the
dialup servers and various private workstations, attach.conf would
have to be updated, or else users would obtain "attach: You are not
allowed to attach a filesystem here" errors. I see no way to automate
this, since private workstation owners decide for themselves what
mountpoints are appropriate, based on their own conception of the
security/convenience tradeoff.
Also, users would have to find out that the sipb locker was "special"
in that 'attach lockername; cd /mit/lockername/a-directory-of-interest'
didn't work (that is, unless a link were installed from /mit/sipb back
to /usr/sipb).
