🚀 go-pugleaf

In article <1991Sep18.021603.260@s1.msi.umn.edu> meuer@roch.geom.umn.edu (Mark V. Meuer) writes:
   In article <1991Sep16.231808.9812@s1.msi.umn.edu> meuer@roch.geom.umn.edu (Mark  
   V. Meuer) writes:

   >I have a NeXT with version 2.1 of the system.  We have emacs 18.55
   >running.  (Please don't tell me to upgrade to version 18.57 unless
   >you can also supply a pointer to diffs or at least s- and m- files
   >for the NeXT.)  There are several machines in our network and we
   >are using yellow pages.  The problems is that whenever I try to
   >find a file (either through "C-x C-f", "emacs file" or through a
   >client talking to the server) emacs freezes completely for between
   >15 and 30 seconds.  The file then loads and everything works fine.
   >In about 1 in 10 times the file loads immediately with no delay at
   >all.

   The problem we had was that /usr/lib/emacs/lock was mounted over
   NFS, and apparently NFS doesn't handle exclusive create as well as
   one would hope.  The command would create the file, but return an
   error saying it didn't.  Since emacs thinks it wasn't able to
   create the lock file, it never removes it.  But since it did create
   the file, all future attempts to open files encounter this lock
   file and force emacs to go through a 20 second loop before
   proceeding.  That was what was causing the delay.

NFS on the NeXT does not do exclusive locks on files, period.  That
might be the reason someone else mentions that they've been doing this
on diskless Suns without problems for some time - maybe Sun's NFS
implements exclusive locks (in fact, considering origins of NFS, I'd
have to bet they do :-).

Later,
--
scott hess                      scott@gac.edu
Independent NeXT Developer      Graduated GAC Undergrad!
<I still speak for nobody>
Old:    PO 829, GAC, St. Peter, MN  56082       (507) 933-8466
New:    RR#4 Box 227 Pipestone, MN  56164       (507) 825-2788