🚀 go-pugleaf

In article <9009041729.AA08606@.dupuis.gr.osf.org.>, macrakis@ri.osf.fr writes:
|>GNU Emacs 18.53.11 on NeXT 1.0.1
|>
|>(This is not an Emacs problem, but a Next configuration problem.  I'm
|>forwarding to bug-gnu-emacs for information only.)
|>
|>On the Next, the PATH_LOCK variable (in paths.h) is not set up
|>correctly (it is currently set to /usr/local/emacs/lock/).
|>
|>Comments:
|>
|>1) /usr/local/emacs/lock does not exist by default on a Next out of
|>the box.  (In fact, /usr/local doesn't exist.)
|>
|>2) the lock directory should be shared by all users of a site, which
|>/usr/local is not necessarily (should it be?)
|>
|>	-s
                 
There is a problem anyway if you have a diskless station, e.g. SUN3/60,
mounting  '/usr' with '/usr/local/gnu/emacs/lock' (for example) in it
from its server. The server is very likely to forbid write operations
even if '/usr' is mounted read-write (default is read only). We use
'/tmp/' for locking but this is not enough since an other emacs running
on an other station would allow editing the same file through NFS. The
same problem is true for example for score files in '/usr/games'. A 
possible solution is to have a dedicated directory for such operations
on one server, export it read-write for all and mount it somewhere on
every station or other server.