Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!caip!nike!ucbcad!ucbvax!UMIX.CC.UMICH.EDU!paul
From: paul@UMIX.CC.UMICH.EDU ('da Kingfish)
Newsgroups: mod.computers.apollo
Subject: quirks when using a bridge ...
Message-ID: <8607282321.AA00172@umix.cc.umich.edu>
Date: Mon, 28-Jul-86 19:21:31 EDT
Article-I.D.: umix.8607282321.AA00172
Posted: Mon Jul 28 19:21:31 1986
Date-Received: Tue, 29-Jul-86 01:28:30 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 24
Approved: apollo@yale-comix.arpa

any bridge users out there?

here is the situation:  i am on one side of the bridge, on my node --
//quasar.  i happen to know that there is a node -- //rambo on the
other side of the bridge that has files i want to access.

but, from my side of the bridge, it doesn't look like //rambo is
there.  lcnode doesn't show it, and doing an ls on // doesn't show it.
but, if i crp to a node on the other side of the bridge, //rambo is
there.  lcnode shows it, ls // shows it, and i can access files there,
etc.

when, from //quasar, i do "ls -l //rambo", or stat(2) any file on
rambo, my // gets locked and stays locked.  is this a bug?  have other
bridge users seen this, or had // lock up?

and why the variance between views of // across the bridge?  is this a
bug, or something that people alrady know about?

from bsd's stat, the program seems to hang in resolve_next_comp().  in
another situation, i think from /com/ld, it hung in
name_$get_entryu().

--paul