On Fri, Oct 13, 2000 at 03:22:05PM -0400, Greg Troxel wrote:
> 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 sends a Store[468] based on the VV from the create/store 0
> and this doesn't match.

Not that crazed, you are completely right.

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

There is a frozen state for already sent CML entries, although I believe
they are `defrosted' in some cases. There is also the issue that the
shadow copies of files associated with Store CML's are not part of the
cml entry, but part of the FSO. This means we can currently only have a
single Store record in our log.

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

Well, ip-firewalls come to mind as more common introducers of similar
one-way connectivity.

Jan