I've recently started to put more and more of my files into coda, so
I'm seeing more problems :-)

I was emacsing a file on a client, and ended up disconnected due to
IPsec flaking on me.  The disconnection was such that venus->vice
packets still got through, but vice->venus did not (I was getting
messages on the console that said packet received for unknown SPI).
After a few minutes I restarted IKE etc. to fix IPsec, and then found
that I had a local/global conflict.   I had not done anything near
this directory on any other clients.  The server had a zero-length
file and the local version had 400-odd bytes.  This was trivial to
repair with preservelocal, but it was very odd that it happened.

I have some crazed speculation on how this happened:

venus does some operations, all is well
network becomes half-disconnected as above
user edits file, causing emacs to create #foo# autosave
venus does Store[0]
			server receives Store[0], does it, acks
venus does not get ack
venus goes disconnected
emacs create succeeds
emacs writes 400 bytes into the file, adding Store[400] to CML

[time passes]

venus coalesces the two stores

connectivity is restored

venus notices the server is up, or cfs cs etc.

venus sends a Store[468] based on the VV from the create/store 0
and this doesn't match.



Now, I don't really understand things very well, but I thought I'd
throw this out.  It might make sense to add a rule that operations
which have ever been sent to any server (but not acked) cannot get
coalesced.  This assumes that the coalescing is the problem, not just
the fact that it's being done as a reintegration rather than a
rexmission of the previous.

I'm guessing that this 1-way connectivity is not that common, aside
from people with problems like me.

        Greg Troxel <gdt_at_ir.bbn.com>