On Fri, Oct 11, 2002 at 08:49:39AM -0400, Matthew R Welland wrote:
> 
> 1. Make the inconsistent file listable but neither readable or writeable
> (this file could possibly be the version as it was on the server before the
> conflict.
>

I believe this already happens, the file in conflict gets converted to
a symbolic link to the coda object id (I think it is the obj id)
 
> 2. For each possible version of the file create a new file in the same
> directory with a naming scheme such as
> <originalname>.host_where_modified.uniquenumber where the
> host_where_modified portion can help the end user choose which copy
> to keep

Hmmmm, without being rude, it sounds like you never actually worked
through a repair session.  This is pretty much what happens when you
start a repair of a conflict, the coda file system is "split" into the
local version and the server version (for a local/global conflict).
By viewing both versions you can use the repair tool to decide whether
to preserve of discard the local modifications (or you could copy off
one version of the file if a manual merge needs to be done).  Once you
have processed the modification list and decided what modifications
stay and which ones go then you commit the changes, end the repair and
then the two "views" disappear leaving a single coda tree again.

> 
> 3. Allow CODA to keep running! Having the filesystem become unavailable due
> to some lock file being inconsistent is not fun.

I am sure Jan can explain better than I, I just have this vague
feeling that keeping the filesystem running in the face of conflicts
could get really messy really quickly.

> Use some standard
> mechanism to notify the end user that there is a problem.

I think someone was working on a sort of monitoring tool that would
let you know when there was a problem.

> What does nfs use
> when a server goes down?
> 

Oh, the ever so subtle hint of any process touching the NFS mounted FS
stopping dead in it's tracks until the server comes back ;-)  If you
are lucky the fs will be mounted interruptable so you can at least
kill the hung process, if you are trying to write then you are pretty
much dead in the water until the server returns (well, there are soft
mounts but they are not recommended for writable volumes because of
the risk of losing data)

> I found the CODA repair process to be very difficult to comprehend and it
> didn't (at the time) work very reliability. The suggested process would be
> understandable to almost anyone in my opinion.
> 

I have had some repairs fail on me but others have worked ok.  The
actual repair process is not simple and it does take a bit of practice
to get the hang of, I am not sure how it could be made simpler - maybe
it just needs to be documented a bit better to better explain what is
happening.

-- 
Brett Lymn