(Illustration by Gaich Muramatsu)
Not that I think it makes much difference but I use tunnel mode for my ipsec not transport mode. I suspect the IPsec part is not relevant, unless the loss of connectivity happens due to IKE rekeying glitches. But I would be very surprised if tunnel vs transport mattered. For the record, I use transport from each machine to the server. have you tried setting the connection to strong? I think so, but this was a transition to disconnected, not write disconnected, so I don't see how that would help. I can try it though. I use CVS on my coda setup a lot, mind you, I do not do cvs operations on the laptop when I am in connected mode (not for any Coda reason, it is just the way my network topology is...), if I am at home then the cvs operations happen on the server so I may be missing something due to the good connection between server and client. If I do do cvs operations on the laptop then Coda is always in disconnected mode, again not for any Coda reason, just the way my network is. I meant to say RCS, not CVS - rcs in coda is much more stressful since the ,v files get modified, whereas in CVS they are on the CVS server. (I would think it pointless and perhaps insane to keep cvs server bits in coda; I prohibit cvs-over-nfs in my workgroup to make sure the cvs server process and files are on the same machine and locking works etc. Plus, this means that the cvs conflict mechanisms are used - doing repair merges on ,v files sounds highly ugly, especially for big commits. But I suppose there is an availability argument to be made, but IMHO coda is not reliable enough to beat a single machine, esp with RAID.) Yes, I have seen this sometimes. The repair just wedges or returns an error and after that the client seems to be a quivering wreck requiring an init to get it right. OK - so I am not the only one seeing this bug. when I hit problems my first move is to grab the tar file in /usr/coda/spool/<uid> so I can keep most of my modifications, at least the ones that were done more than 10 minutes ago. I should have done this; I had thought that the server had not got the updates, and I'd be able to just retype the 1-line change I was trying to make. A secondary brokenness (not sure where) was that the server ended up in an inconsistent state (0-length ,v file) that RCS tries to avoid by using rename(2).Received on 2002-09-18 18:32:58