[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: Wed, 20 Sep 89 11:23:04 EST
Why is it that when I make changes to the NAMESPACE some of the
machines don't notice? For instance, one machine on the network went
away, and we got another (unix machines), so I edited the namespace
appropriately. But some of the machines still list that deleted machine
as a dead connection in PEEK on NETWORK? Rebooting does not help, but
Reset Network gets rid of it until the next time I reboot.
As the Namespace Editor tells you when it finishes saving an object:
Other servers and hosts will not get updates until they ask something of the
This is by design. Changes to the namespace are not broadcast; at a large
site like Symbolics or MIT, the constant barrage of changes would swamp the
network. To keep network traffic to a minimum, the namespace server only
sends information in response to a query by another machine. :Reset Network
forces a namespace update by calling NETI:INITIALIZE-NAMESPACES-AND-NETWORK,
which asks the server for a quick update. This function is supposed to be
called at cold and warm boot as well.
How is it that all the lisp machines know about the new machine I
added, but some still think the one I deleted is out there? Is info
cached in a world file overriding the present namespace? Does this
behavior conform with the way the namespace works, or it is a local
bug in our system?
In part this is because the theory of deleting objects from the namespace has
some loopholes, in part it's because there is a bug in the deletion code which
leaves known deleted objects in a cache. I am working on a solution to the
A few days ago I logged into a freshly booted machine as
LISP-MACHINE. I then edited and attempted to save a file. Instead
of saving the file, the machine writes, "Who are you really?"!
Bill <email@example.com> || ...!purdue!bouma
This is a feature; if you supply a user name, the operation proceeds. The
user name that you supply is not checked in any way.
Logging in under any user ID with a type field of DAEMON in the namespace will
cause this behavior. It's intended to remind conscientious users to identify
themselves when saving files (et al) under an alias. Of course, there's
nothing preventing less conscientious people from supplying another alias.
-- Chuck Fry (Chucko@Riverside.SCRC.Symbolics.COM)
Symbolics Software Support