[6109] in Release_7.7_team
Re: Reworking liblocker
daemon@ATHENA.MIT.EDU (Xavid)
Wed Dec 3 22:32:29 2008
Cc: Jacob Morzinski <morzinski@mit.edu>, release-team@mit.edu,
athena10@mit.edu
Message-Id: <72DC63A1-3A1B-4E8F-BA39-A651BFDE9BC0@mit.edu>
From: Xavid <xavid@MIT.EDU>
To: Anders Kaseorg <andersk@mit.edu>
In-Reply-To: <alpine.DEB.2.00.0812032156450.11053@vinegar-pot.mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Wed, 3 Dec 2008 22:31:43 -0500
X-Spam-Flag: NO
X-Spam-Score: 0.00
Why not have running "attach" (but not the automounter) check if the
locker would normally attach at /mit/lockername, and if not act like
ln -s?
This would work exactly the same as broder's proposal in the "normal"
cases we already get right, but continue to have the current semantics
in the cases that it doesn't get right. In particular, any locker
that mounts at a nonstandard place in /mit would only be visible there
to the current user, and lockers that mount outside /mit would work
fine, but only if you're root (or at least can create files there).
It does have the side-effect of keeping new aliases for things that
are currently created by the automounter (/mit/emacs@raeburn.org
always gets you there, but /mit/kr-emacs only gets you there after
running attach).
~Xavid
