> > 	Unfortunately, the conflict resolution process was frustrating because
> > it would show identical files in "local" and "global" down to the file
> > size and time stamp.  The checklocal command inside the repiar utility
> 
> cfs getfid would probably show a different version-vector/store-id for
> the local and global files. Coda never uses things like size or
> timestamp information to detect conflicts.

	But what about checksum or md5 hash?  If the local file and the global
file have different version-vectors/store-ids it seems reasonable for
the autorepair facility to check the checksum/hash/whatever to see if
the files are in fact the same.  If the files are identical in content
and meta information (date, etc.) then the resolution should be
automatic.  Or am I missing a point that makes this difficult to
implement?

> Even when venus is more patient we cannot guarantee that there will not
> be a conflict. That is because everything is done optimistically. 

	Understood.

> entries for reading. Any mutating operation would first have to check if
> the objects in question haven't changed, and lock them to prevent
> concurrent updates.

	Sure, this all makes sense.  But what of the case where only one client
ever touches a file.  That is, when a conflict is caused not because two
clients have written the same file, but because or an RPC2 timeout.

> I strongly believe that connected mode (and cfs strong) mostly provide
> the user with the perception that he won't get conflicts, and in 99% of
> the cases this perception is probably true. But the remaining 1% will
> still cause conflicts or disconnections and reintegrations. So I'd
> rather work on making (write-)disconnected mode, reintegration and
> repair reliable enough so that people don't really have a need for
> connected mode anymore.

	This is a point that should definitely be made in the manual or the cfs
man page.  It never occurred to me that strongly connected mode might be
*less* reliable than weakly connected or write-disconnected mode.

> But to have reliable conflict resolution with ASRs requires repair to
> work in all possible situations and right now there are still far too
> many cases of unnecessary or unrepairable conflicts.

	By application-specific-resolution, do you mean filetype-specific
resolution?  That is, would teh server look at the type of file and use
an appropriate resolution script or policy according to that?  It's an
interesting concept...

> The only other reason for connected mode that I see is because people
> want their updates to be visible on other clients as soon as they 'save
> a file', but that can be done with a synchronous mode where we force a
> reintegration before returning back to the application.

	Right, having updates appear immediately is usually quite desirable in
our case -- at least for certain volumes.  Is there another way to do
this besides cfs strong?  Is there a cfs fsync planned for the future?

	I appreciate your humoring all my questions...

-- 
Patrick Walsh
eSoft Incorporated
303.444.1600 x3350
http://www.esoft.com/