Hi Jan, Your both emails were very helpfull for my coda learning and I appreciate how much time you spend with elaborating this including the third party referenced SW.
Maybe my comment can help a little. I had not found any thing related to the point, that the problems occurent only after movement to replicated solution. Jiri 02. lis (Úterý) v 05:24:39 CET 2004, [EMAIL PROTECTED] napsal(a): > On Mon, Nov 01, 2004 at 09:34:10PM -0500, Jan Harkes wrote: > > On Mon, Nov 01, 2004 at 02:14:50PM -0800, redirecting decoy wrote: > > > So tell me, how is it that I can't make this nice > > > little filesystem function correctly. I "guess", the > > > > Not sure, my current guess is that there is something whacky with the > > networking setup. Your servers might be multi-homed, firewalled, or some > > other reason why the server cannot set up a working connection back to > > the client. > > On closer look at the log you sent me, the RPC2_NAKED message is once > the callback connection was already bound and happens when the first > callback RPC is sent to test the connection. > > It happens when the side of the connection on the client was destroyed, > but I haven't found a reason why it would be. > > > > 2) cfs reconnect > > > *Note: I have never been able to get this command to work. > > > > cfs disconnect activates a 'fail filter' in the RPC2 layer. Basically > > this filter quietly drops any packet we receive or try to send. There > > are other filters available that slow down packets to simulate a modem > > (low bandwidth) or a satellite link (high latency) connection, but those > > are mostly for experiments and not enabled by default. > > and cfs reconnect simply removes the filter, but doesn't reprobe the > servers. > > On Mon, Nov 01, 2004 at 02:14:50PM -0800, redirecting decoy wrote: > > Thanks in advance, I'm going to go hide under a rock. > > I hope there is enough room there for me if this turns out to be some > stupid bug. But for now I have no idea what could be causing these > problems. > > Jan >
