> I think that the part where we associate parent directory information
> during lookup instead of getattr is already done in some experimental
> code which changes the way conflicts are expanded.

	OK, we'll sit tight and wait for that.

> > 	I don't understand why the versions are different after the delayed
> > COP2 hits.  When the VVs are set to be identical, then the COP2 hits, it
> > should hit with the same VV.  So why would this cause a conflict?
> 
> COP2 indicates on what other servers an operation completed, so it
> updates the slots in the version vector that do not refer to the local
> server. Consider a volume with two replicas during a normal operation,
> 
> 		server1		server2
>  Initial state	[0 0]		[0 0]
>  Store foo	[1 0]		[0 1]
>  COP2		[1 1]		[1 1]
> 
> 
> Now when we add the resolve before the COP2
> 
> 		server1		server2
>  Initial state	[0 0]		[0 0]
>  Store foo	[1 0]		[0 1]
>  Resolve	[1 1]		[1 1]
>  COP2		[1 2]		[2 1]

	Huh.  OK, thanks for explaining how this works.  I don't suppose we
could then auto-resolve again so that we wound up with this:

		server1		server2
 Initial state	[0 0]		[0 0]
 Store foo	[1 0]		[0 1]
 Resolve	[1 1]		[1 1]
 COP2		[1 2]		[2 1]
 Resolve	[2 2]		[2 2]

?

> Strange, obtaining new tokens shouldn't interrupt any pending RPC2
> calls. The connection should get dropped once the reply is received and
> the next operation will setup up a new connection based on the new
> token.

	It may not be.  This was an assumption based on those log messages and
a guess from the server crash.  I could be off-base here.

> Can't do that, every token contains a unique key which is used to
> negiotiate session keys of the connections. We can't keep using the
> old token/key. Besides the new token might be for a different Coda
> identity so we might have completely different access rights.

	Okay.

-- 
Patrick Walsh
eSoft Incorporated
303.444.1600 x3350
http://www.esoft.com/