> Ehh, if the file is not readable and not writable, how exactly is it
> different from that symbolic link. And I can do a quick "find . -lname
> '@*'" to find all the conflicts in my volume.

Because it is a symbolic link with a strange name so it is VERY confusing
to a non-technical user.

> Well, heard of 'cfs br' (aka 'cfs beginrepair').

This is the piece I was missing. Several times I wasn't _sure_ which
version of a conflicted file I wanted to keep and within the repair tool I
couldn't figure out what was needed. As I said this was some time ago and I
think I eventually ended up with a conflict so bad I lost everything and I
gave up in frustration.

> $ ls /coda/foo
> lr--r--r-- /coda/foo -> @7f00003.32.123
> $ cfs br /coda/foo
> $ ls /coda/foo
> -r--r--r-- /coda/foo/verdi.coda.cs.cmu.edu
> -r--r--r-- /coda/foo/mozart.coda.cs.cmu.edu
> -r--r--r-- /coda/foo/marais.coda.cs.cmu.edu
>
> 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.

> (or instead of the last two, filerepair file /tmp/keepthis)
>
> So except for the 'cfs br/cfs er/removeinc' it's all standard Unix
> tools.
>
> It is true, if you have an unresolved conflict in some directory the
> 'state' of all objects in the whole tree underneath this conflict is
> suspect. Similarily when reintegrating, once a reintegration fails for
> some reason, we can't simply push the rest through, because that might
> actually create more conflicts than necessary and it would be strange to
> have an uptodate postscript document which is 'derived' from an outdated
> version of the latex file.
>
> > > > Use some standard
> > > > mechanism to notify the end user that there is a problem.
>
> The problem is twofold. First of all servers don't know whether there
> are any conflicts or not, and even a client just doesn't know until it
> does a getattr for the file in conflict. So (except for reintegration)
> conflicts are only detected when we look at them. Then resolution is
> attempted first, and only when that fails the object is show as a
> conflict to the user.
>
> All of this happens at the time that a user would try to access the
> file, or list the directory. So we can't really give you any advanced
> warning, the moment a dangling symlink shows up in the directory is
> typically the moment Coda figures out something is wrong.
>
> The only exceptions to are hoard walks (active prefetching of files) and
> reintegration conflicts. However these happen in the background
> typically without any specific 'user' action that triggers them. So when
> we discover a conflict this way, which of the local users with Coda
> tokens should we notify. And maybe more importantly, how.
>
> Currently we use 'codacon' as the main method of informing users of
> these conflicts. Now codacon has traditionally been almost more of
> simple to check debugging tool (no persistence like venus.log, so it
> doesn't matter how much data is written to it) and contains a lot of
> other informations that most users probably aren't interested in.
>
> > > I think someone was working on a sort of monitoring tool that would
> > > let you know when there was a problem.
>
> Yes, it is basically a frontend for codacon, that filters out the most
> interesting stuff and does some additional queries with 'cfs' (i.e.
> amount of CML entries, quota usage etc.) I think it's on the Coda ftp
> site, probably in pub/contrib or something.
>
> > 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?
>
> Huh, I don't think I ever got a popup message from AFS on my screen, but
> then again, my desktop doesn't have AFS and I would be severely
> impressed if the remote machine would manage to pop anything up on my
> local machine.
>
> > 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?"
>
> Pretty much how repair works, except that it has one additional stage,
> where it knock you on your head and says "Hey you got a conflict, stop
> what you're doing and go fix it", which is a lot better than
> automatically expanding it and whatever programs that caused the
> conflict (or hit it) will reliably fail instead of trying to blunder on
> (f.i. create files in the expanded conflict).
>
> > SYSTEM Message: CODA has detected a file in conflict:
> > /home/matt/documents/file.sdw
>
> What where do you expect this 'system message' to come from? How does
> the system know you care? And how will you see it when it writes itself
> to the terminal up in the middle of 100's of lines of make output.

Good Points. In my case I assume it is the kernel on the machine running
the afs client daemon and I get to see the messages because I usually have
several xterms open. Others might not see the messages.

> > % 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
>
> Allowing regular 'rm foo', 'mv foo bar' and translating that to an
> actual operation on the CML and the remote servers that manages to fix
> the conflict is harder than it seems. Some of the required code is
> already there (in the repair tool :), but a lot of it is still quite
> difficult.

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.
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).
      ii. Get a list of conflicting files (find ...)
      iii. For each conflicting file
            a. cfs br file
            b. copy the files for safety
            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?

Matt
--