On Thu, Mar 18, 2004 at 08:57:36PM +0100, Daniel Tschan wrote:
> > One thing that I do know is that the kernel is unable to turn a
> > 'conflicting' directory into a dangling symlink as long as it has an
> > active reference. Repair only recognizes a conflict because of the
> > dangling symlinks.
>
> This is not the case here. Conflicting files are correctly changed into
> dangling symlinks. The beginrepair command of the repair application
> changes the symlink into a directory containing a local and a global file
> as expected. But the listlocal command then says that there are no
> mutations even though the cml file mentioned by repair correctly lists
> them. Therefore I'm unable to resolve the conflict. The logs don't show
> any errors. Any ideas?

Interesting, listlocal uses a file in /tmp that is written by the venus
process and read by repair. Maybe fedora has some changes to make
tempfile creation a bit safer (which break this cross-user/process
sharing of the temporary file.

checklocal should check what the current problem is. The is also a file
in /usr/coda/spool/<uid>/<volname>.cml. This is occasionally updated,
'cfs ck' triggers a new checkpoint to this file. The first entry in this
file should be the conflicting operation. But if repair doesn't see it,
I don't know how it could be repaired.

The other solution is to copy the associated tarball (volname.tar in the
same directory) to a safe place, then purge the modification log with
'cfs purgeml', and extract the tarball. This doesn't cover renames or
removes and such, but at least no data should get lost.

Jan