> 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)

Converting the file to a symbolic link is NOT analogous to what I am
suggesting. Changing the file to a symbolic link is complicated and
confusing to a casual user. Leave the file there as a normal file but set
the permission's such that the user MUST take action before accessing the
file again. Also, if CODA knows of other variations of that file make those
also transparently available for the user to decide what to do with.

> > 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.

Well, yes, it has been a long time. As I remember it you can't see the
local vs global files without using the repair tool. If I had a binary file
I had to do several steps to be able to view that file in its respective
program (e.g. staroffice). If the conflicting files are made available as
ordinary files with special, recognizable names, then I can use whatever
program I want for viewing the contents of the file and I can use ordinary
Unix tools (rm, mv, cp, chmod, or even midnight commander, konqueror etc.)
to restore my file the way I want. I could even - very quickly, and without
using any special tools - bring up the conflicting versions of my file into
say, StarOffice, and use cut and paste to merge my conflicting changes.

> > 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.

I have a hard time believing this but perhaps so. The consequence of this
is that for many people CODA will never be usable as an every day FS.

> > 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)

Yup, that sucked. I think I was actually thinking of the messages that AFS
puts on the screen when a server goes down. What mechanism do they use for
that?

> > 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.

I disagree that documentation will solve the problem. The repair model is
arcane and the needed data (the various versions of the conflicting files)
is not transparently available to the end user. Many of the conflicts I
remember getting were for files I didn't even care about. Lock files,
temporary files etc. To resolve those I should be able to use ordinary Unix
tools to quickly remove the offending file and get back to work. Of course
I was hitting pretty hard on CODA to see what I was up against but even in
mild experimentation I had too many conflicts and too many problems in
addressing those conflicts.

I just took a few minutes to read through the repair documentation and I am
even more convinced that the existing model will never fly with anyone
except very savvy end users. If a directory is in conflict due to parallel
creation of a file in that directory by two disconnected users why all the
hidden behavior. Files mysteriously become a weird series of characters
(yes, I know it's a link to a special file), I can't just mv the file out
of the way. I can't bring it up for viewing. I can't just rm it.

The three scenarios depicted in the user and system administrator manual
can all be mapped to the mechanism I describe and thereby eliminate the
need for the repair tool, make the repair process transparently available
to existing gui based file management tools, and make the conflict repair
process explainable in normal language. "Yup, your file conflicted, there
is the original, there is the one modified on host foo, there is the file
modified on host bar, which one do you want to keep?"

E.g.
SYSTEM Message: CODA has detected a file in conflict:
/home/matt/documents/file.sdw
% cd /home/matt/documents
% ls
---------- file.sdw
-rw------- file.sdw.foo.1
-rw------- file.sdw.bar.1

% ~/office52/soffice file.sdw file.sdw.foo.1 file.sdw.foo.2 &
[user inspects files]
% rm file.sdw
% mv file.foo.1 file.sdw

Done!
NOTE: It might be better to put the special name stuff at the front of the
file name since maintaining file extensions could be helpful. In my example
instead of file.sdw.foo.1 perhaps foo.1.file.sdw would be better.

Matt
--

> --
> Brett Lymn