On Fri, Jul 23, 2004 at 05:20:20AM -0400, Martin Emrich wrote:
> IMHO, there should not have been any conflict at all, as even the parent 
> directory never existed on the server or another client. In fact, by the time 
> the error appeared, I used this volume from only one client, my notebook.

The actual conflict is really only the first operation in the CML
(/usr/coda/spool/<uid>/<volumename>.cml). But I'm pretty sure that we
mark all depending objects as a conflict as well.

So the conflict could very well be the creation/removal of the
directory, which marks the creation of any files within that directory
as a conflict. The thing is, if there was no problem the whole
operation would have been optimized away by the client. However
something is going on, simply as there is (clearly) something we're
trying to reintegrate.

Did you create a file in the removed directory and renamed it to some
other location? Could the client have been disconnected while trying to
write to the server. If that happens in connected mode, the operation is
logged but if the store actually succeeded on the server we end up with
a conflict on the reintegration attempt. There are several reasons why
even a single client can be hit by a conflict, many of these are simply
very hard to correctly fix implementation problems. Cross-directory
renames and aborted store operation are the two that I know of.

> > The second problem is that repair is very paranoid and refuses to do
> > anything if it can't reach all copies. That really shouldn't be
> > necessary in all cases, if a server is dead or unreachable it would
> > still be useful to perform a partial repair, even though the conflict
> > would come back as soon as the missing server returns.
> 
> All my repair attempts happened at home while being strongly connected to the 
> server.

It doesn't matter if the object (and possibly even it's parent
directory) do not exist at any server. Since we can't compare to
anything the repair tool can not discover what the underlying problem
is.

Jan