[66] in Info-AFS_Redistribution
NeXT 2.0 + AFS + ~/.NeXT
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Sat Jan 26 18:37:14 1991
Date: Sat, 26 Jan 91 17:36:29 EST
From: cthixton@next.com
To: "Mark W. Eichin" <eichin%ATHENA.MIT.EDU@ricevm1.rice.edu>
Cc: "Liz Hines - Transarc" <Liz_Hines@transarc.com>,
During the initial beta testing over at CMU, we found most of these
problems. Your Transarc technical support folks should be able to
address these problems.
1. Although the 2.0 beta version of AFS will load on a 2.0 NeXT
computer, there are side effects which affect the creation of .NeXT
files. Make sure you are Not running either Beta AFS or Beta 2.0.
Both must Both be the Final release. To check to see if you are
running NeXT OS 2.0, check /usr/adm/software_version which should
read '2.0 Warp6.4'. Check with your support center on how to verify
which version of AFS you have. The reason that it is taking so long
to login is because the appcache.wmd file does not exist, so every
app in /Local{Apps,Admin}, /Next{Apps,Developer,Admin}, ~Apps is
parsed for its file name list and icons. This can take a while.
2. When importing files which either Librarian, Websters or any of
the Digital Library apps use over AFS, you will have to turn on lock
access for the .index directory (this is normally turned off). These
apps use flock() to insure that no one else tries to modify the
indexes while they are being searched. There is a known AFS bug where
this will not work when the AFS volume is replicated. Also, do not
import /NextLibrary/Fonts.
3. The beta version of loginwindow that is available has one known
bug in it which affects the Services (read Menu) option. We hope to
get this addressed shortly.
Cal Thixton
NeXT Computers
Begin forwarded message:
Date: Wed, 9 Jan 91 02:13:20 -0500
Reply-To: NeXT Campus Support <NEXTSUPP@ricevm1.rice.edu>
Sender: NeXT Campus Support <NEXTSUPP@ricevm1.rice.edu>
From: "Mark W. Eichin" <eichin%ATHENA.MIT.EDU@ricevm1.rice.edu>
Subject: NeXT 2.0 + AFS + ~/.NeXT
To: Multiple recipients of list NEXTSUPP <NEXTSUPP@RICEVM1>
We're running 2.0 with Transarc AFS (so that we can have common home
directories and all that other Athena Stuff :-) and discovered that
if ~/.NeXT is a symlink to a local directory, things work fine, but
if
it is actually a tar copy of the local one, nothing launches! If you
have the Command-P process lister up, it shows the applications stuck
in "launching" state, and the buttons stay whited out.
Any ideas on what's so special about the files in .NeXT?
_Mark_ <eichin@athena.mit.edu>
MIT Student Information Processing
Board
ps. Starting Preferences and leaving it alone for a *long* time (15
minutes?) eventually gets it started; changing one option takes over
a
minute. So what is it trying to do? If there's some specific call
it's
making that is unusual (I can edit the files with emacs with no
trouble, so it's not just open, read, write, and probably not
stat...)
Date: Wed, 9 Jan 91 07:54:28 -0500
Reply-To: NeXT Campus Support <NEXTSUPP@ricevm1.rice.edu>
Sender: NeXT Campus Support <NEXTSUPP@ricevm1.rice.edu>
From: "Mark W. Eichin" <eichin%ATHENA.MIT.EDU@ricevm1.rice.edu>
Subject: Re: NeXT 2.0 + AFS + ~/.NeXT
To: Multiple recipients of list NEXTSUPP <NEXTSUPP@RICEVM1>
>>We're running 2.0 with Transarc AFS (so that we can have common
home
>>directories and all that other Athena Stuff :-) and discovered that
>>if ~/.NeXT is a symlink to a local directory, things work fine, but
if
A bit more searching indicated that the "db" library, which
NXGetDefaultValue (and related fns.) are built upon makes use of
"flock". AFS apparently changes the semantics of flock slightly - it
acts as if always called with the LOCK_NB option, so that flock can
*always* return EWOULDBLOCK even though you're expecting it to wait
for the lock to be released (and grabbing it for itself) before it
returns...
Now, I could probably work around this by modifying flock()
in
libsys_s.a to loop until it actually acquired the lock. Any reason
that I can't just replace it with ar? or any better solutions?
_Mark_ <eichin@athena.mit.edu>
MIT Student Information Processing
Board
