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
