On Tue, Jan 22, 2002 at 07:17:11PM -0500, Tom Carroll wrote:
> cfs br help_zh_CN
> ls -l help_zh_CN
..
> lrw-r--r--    1 root     nogroup        27 Jan 21 09:39 global -> @7f000005.00002353.00000c58
> drwxr-xr-x    2 oracle   nogroup      2048 Jan 18 16:52 local
> 
> cfs cs
> Contacting servers .....
> All servers up

Ok, I might have been a bit verbose, let me quote the relevant parts of
my previous email,

    Run, 'cfs br' (beginrepair) on the object in conflict, it should then
    expand into a directory, do an 'ls -l' on the directory and it should
    show

	global -> #volumename
	local/

    if the client is disconnected from the servers. In this case, check the
    servers and network connections and run 'cfs cs' to force a server
    probe, which should typically bring the global volume back.


	global -> @7fxxxxx.xxxxx.xxxxx
	local/

    if there is an underlying server-server conflict. The only way to fix
    this is to go to the same location on another client and fix the
    server-server conflict first. After that the reintegration should just
    start again, although you might get a local-global conflict if the
    server-server repair had to make any changes to the replicas.

So you obviously have a server-server conflict on the global object
which needs to be repaired from _another_ client.

Jan