On Fri, Apr 12, 2002 at 06:14:45PM +0200, bruno wrote:
> Here is my scenario:
> In a mounted volume (ie /coda/test), a file will be modified by a
> disconnected client but also modified on the server. That gives
> something like (client-A and client-B are initially connected):
> 
> client-A: cfs wd ; cfs disconnect
> client-A: modify /coda/test/foo
> client-B: modify /coda/test/foo
> client-A: cfs reconnect ; cfs wr
> 
> First thing that's look suspicious after write reconnect in the
> venus.log:
> 
> ...
> ClientModifyLog::COP1: (test), 1036 bytes, returns 198, index = 0
> ...
> 
> The error code 198 (unknown on Linux) is then propagated as the result
> of reintegration.

198 is EINCONS, inconsistency detected.

> As expected, /coda/test is now a dangling link:
> 
> lr--r--r  root   test -> @7f000001.ffffffff.00080000
> 
> but trying repair just don't work:
> 
> repair > beginrepair
> Pathname of object in conflict? []: /coda/test
> No such replica vid=0xffffffff
> Could not allocate replica list
> beginrepair failed.
> 
> I must say, I'm stuck :(
> Any ideas ?

Ehh, it shouldn't do that.

What do you get if you do

    cfs beginrepair /coda/test
    ls -lR /coda/test
    cfs er /coda/test

It should show something like

    /coda/test/local
    /coda/test/global

Both should be files, one the copy on the servers and the other the
local copy.

Sometimes global is a dangling symlink too, indicating that there is a
server-server conflict underneath this local-global conflict. Currently
you need another client to fix the server-server conflict first.

Jan