I have a conflict and can't repair it.

All machines are NetBSD 4 or current, and i386.
Server rvm is really old - probably 8 years.
Server is a xen domU.
coda is either 6.9.2 or recent cvs.
Coda works fine in general except for
  getcwd fails due to lookup(..) failing in venus


I keep files in cfs, which stores ciphertext in a regular filesystem
which in my case is coda.

I edited a file in cfs last night, on a machine on the same subnet as
the server, and this morning gcodacon showed red circle, which is
conflict.  (I had not been running gcodacon on the machine when editing,
and for no particularly good reason did not edit on the machine I was
sitting at.)

But, the conflict is not behaving normally.

When one creates a file in cfs, two files are created in the ciphertext
filesystem.  One has a name which is the encrypted name of the file, and
it's in hex.  For 8-character files, this is something like
0123456789abcdef.  This file contains ciphertext in a fairly normal way.
Then, there's a symlink ".pvect_0123456789abcdef -> 01234567" which
stores the IV.

The symlink is present on client and server and matches.

The main file can be seen from other clients, and is zero length.
On the conflicting client, it shows up:

-rw-r--r--  1 root  65534     29 Aug 30 11:02  [filename redacted]

the rest of the files have user gdt.

It has 3558 bytes if I read it, and cat'ing it to a regular (ufs, no
coda, no crypto) filesystem I can then 'cmp' it to the file extracted
from cml/tar from cfs ck and it matches.

Note that with all this probing I am not exercising cfs - I'm just
looking at ciphertext.

So I think this file is the one in conflict, but it only seems to be
partially in conflict.

repair > beginrepair [filename redacted]
Error beginning repair: pathname not leftmost
beginrepair failed.

I can't find the filename in venus.log or console in /usr/coda/etc

Restarting venus did not change the behavior.

Any clues?  In a few hours I'll purgeml and restore the ciphertext from
the cml tar file.