(Illustration by Gaich Muramatsu)
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. JanReceived on 2004-07-30 11:44:47