On Fri, Oct 11, 2002 at 03:11:34PM -0400, Matthew R Welland wrote:
> > If you don't want to use the repair tool (which btw. automates a lot of
> > the actual repair operation) you can always do,
> >
> > cfs br file
> > ls -l file
> > cp file/version /tmp/keepthis
> > cfs er file
> > removeinc file
> > cp /tmp/keepthis file
> 
> I find the above easier to understand than the repair description. In fact
> it seems like it would be easy to write a script that would meet my
> requirements. Perhaps I gave up on CODA too early. I would suggest adding
> this sequence to the documentation if it isn't already in there as it
> really helps understand the repair process.

This existed before the repair tool. The repair tool was 'invented' to
simplify/automate the process, so this way of repairing conflicts got in
a state of 'disrepair' :) Last year, an undergraduate student worked all
summer on the application specific resolvers, which are easier to write
using these older primitives, so a lot of his time actually ended up
going into making sure that removeinc actually worked reasonably well.

The other thing he added, which I still look forward to using some day
is dealing with the server-server 'fixfile' for reintegration conflicts,
but I haven't yet finished up the necessary venus changes. This fixfile
actually contains operations like 'create/remove/rename foo' and should
allow for a more shell like repair tool.

> I see. So, how about the following as a methodology for using CODA in an
> environment with non-technical users:
> 
> 1) Break up the file space into as many volumes as possible. E.g. by home
> directory, project etc. IIRC this helps reduce conflicts.

Correct, we actually often have multiple separate volumes per user. f.i.
published papers, doubly (or singly) replicated. Volumes for email,
singly replicated volumes for object files (not a big deal when they're
lost). Each volume 'type' has it's own replication and backup policy.

> 2) Provide a script that does the following when "my files aren't
> available, help!"
>       i. Restart venus? (use sudo or ask for root password).

I wouldn't automatically restart venus. First thing is probably to get a
coda token, which is the most common problem for 'lost access' in my
experience. Then forcing a reintegration, as locally dirtied directories
block the client from fetching the updated copy from the server, so new
files aren't visible.

If the reintegration fails, then

>       ii. Get a list of conflicting files (find ...)
>       iii. For each conflicting file
>             a. cfs br file
>             b. copy the files for safety

Ehh, the local modified copies are already in
    /usr/coda/spool/<uid>/<volume>.tar

So copying that tarball to a safe location would probably be quicker.

>             c. Ask the user which file they wish to keep
>             d. cfs er file
>             e. copy the requested file back
>       iv. All done?
> 
> How often will this not be sufficient?

This could very well be the basis of a nice graphical repair tool. The
thing is that as soon as you put more smarts into it, it has a chance of
becoming as difficult to use as repair. One thing I'm working on is to
slowly unify local-global and server-server conflict handling. That
should simplify the work for any type of repair tool, and also the
'concepts' that the user needs to understand when faced with conflicts.

Jan