🚀 go-pugleaf

    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
-------