[2469] in Release_Engineering
Re: [jtkohl@ATHENA.MIT.EDU: decmips 7.1H: msgchk]
daemon@ATHENA.MIT.EDU (Richard Basch)
Mon Nov 5 09:39:59 1990
Date: Mon, 5 Nov 90 09:39:44 -0500
To: jik@MIT.EDU
Cc: rel-eng@MIT.EDU
In-Reply-To: rel-eng[2468]
From: Richard Basch <probe@MIT.EDU>
[2468] daemon@ATHENA.MIT.EDU Release_Engineering 11/05/90 04:05 (121 lines)
Subject: [jtkohl@ATHENA.MIT.EDU: decmips 7.1H: msgchk]
Date: Mon, 5 Nov 90 04:05:20 -0500
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
To: bug-pmax@ATHENA.MIT.EDU, rel-eng@ATHENA.MIT.EDU
Two questions:
1. Is this fixed on the packs the pmaxen are currently using (it
appears to be, but I may be wrong)?
Yes, it's fixed... I fixed up the structure of /afs/athena/system/
2. Is this going to be a problem in 7.2?
No... However, it does seem that the number of symlinks allowed is
smaller. If people choose a shortcut and use a path (or equivalent
path, such as /afs/athena/...) well, then they may lose. This is also
the case with the normal VAX and RT packs. We simply don't support
paths that are not registered in Hesiod.
The problem was discovered a few hours after we switched everyone from
the AFS packs in the testers' cell to those in the athena cell.
Apparently, when I was re-organizing /afs/athena/system/, I was trying
to accomodate the old decmips packs that suffered from the symlinks
problem, and forgot to switch it so the number of links was reduced when
most of the PMAXen were changed to have an @sys value of pmax_ul3.
jik
----- Forwarded message
Date: Thu, 11 Oct 90 09:27:05 EDT
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: bugs@ATHENA.MIT.EDU
Subject: decmips 7.1H: msgchk
X-Us-Snail: MIT Room E40-300, 1 Amherst St., Cambridge, MA 02139 USA
System name: quicksilver
Type and version: KN01 7.1H
Display type: PM-MONO
What were you trying to do?
run msgchk from my login scripts.
What's wrong:
/usr/new/mh/bin/msgchk: Too many levels of symbolic links.
