On Mon, Nov 04, 2002 at 11:10:32AM +0100, Steffen Neumann wrote:
> I now experienced repair problems, I have a file in conflict,
> and I get
> 
> 	Gaspra(sneumann):techfoils>repair
> 	[...]
> 	"endrepair" or "quit" to terminate the current repair session.
> 	repair > beginrepair Makefile
> 	Too few directory entries
> 	Could not allocate replica list
> 	beginrepair failed.
> 	repair > 
> 
> even though it looks as if it had succeded.
> There are local/global versions of that file,
> I just can't get rid of the local version.

Ehh, local/global versions of the file? The conflict is still expanded,
you might want to collapse the expanded tree with "cfs er" first.

Could you check from another client to see whether the object is a
dangling symlink on the server?

If the conflict was expanded due to an earlier (failed) repair session
that could be a reason for the repair error messages.

> Any ideas ? Did Greg fix his problem ?
> How to dump just this one object in conflict ?

Maybe "removeinc object" would work.

> venus.log
> [ L(18) : 0000 : 10:58:19 ] LocalInconsistentObj: objFid=7f000001.6932.b86b
> 
> 	Gaspra(sneumann):techfoils>cfs flushobject 7f000001.6932.b86b
> 	VIOCFLUSH: No such file or directory

In many cases flushobject is pretty evil to the venus internals. I hope
it failed here because it didn't want you to destroy a dirty object with
associated CML entries, and not because it already flushed the dirty
data on an earlier attempt.

Jan