> 
> Ok, it looks like there is a server-server conflict, which caused the
> reintegration to fail. As a result the local-global conflict is 'hiding'
> the real problem and because of the way the conflict expansion works we
> can't repair this from a single client. You would have to repair the
> server conflict first from another client. I have been working on a
> method which combines both local-global and server-server expansion on
> the client in one operation, instead of seeing the local copy and the
> replicated version it would expand into all available versions, i.e.
> 
>     $ ls -lF 121canon/
>     total 3
>     drwxr-xr-x    2 maur     nogroup      2048 May 21 12:10 localhost/
>     drwxr-xr-x    2 maur     nogroup      2048 May 21 12:10 server1/
>     drwxr-xr-x    2 maur     nogroup      2048 May 21 12:10 server2/
> 
> The expansion works now, but collapsing it back is still a bit iffy,
> especially the parts where we have to correctly clean up the local state
> and deal with possible client restarts. Also, the repair tool needs to
> be taught how to deal with combined reintegration and resolution
> conflicts, both of which are entirely different codepaths at the moment.
> 
> > server1 log entries:
> > 08:26:09 VGetVnode: vnode 27000009.37 is not allocated
> > 
> > server2 log entries:
> > 08:26:09 VGetVnode: vnode 29000008.37 is not allocated
> 
> It is curious that both servers claim the object doesn't exist, I would
> expect that at least one would have the object, while the other fails.
> But right now, you'd probably want to look if a second client sees a
> server-server conflict.
> 

Well interesting... I see nothing on another client for the directory
'121canon'.. Which would explain why the servers don't think it's there.

When I was doing this, I had two copies going at the same time, so there was a
lot of network traffic. 

Is there some state (rvm on a client or server) I should save off before
doing a 'venus -init' on the client with the conflict?