[mod.computers.apollo] quirks when using a bridge ...

paul@UMIX.CC.UMICH.EDU ('da Kingfish) (07/29/86)

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

mishkin%UUCP@apollo.UUCP (Nathaniel Mishkin) (08/04/86)

    any bridge users out there?

Sure, we have about 20 networks here.

    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.

"lcnode" shows you only those nodes on the net to which you are directly
attached.  The contents of any particular node's "//" directory are merely
a cache of the node names and addresses that you have referred to
(recently).  The cache is over the database maintained by the "ns_helper",
the replicated database of node names and addresses.

    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?

    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().

This sounds like a bug.  The only question is whether the hung "ls" or
"ld" was the source of the locked "//" or merely suffering from something
else having left it locked.  Does this happen all the time?

            -- Nat
-------