On Fri, Oct 11, 2002 at 12:39:11PM -0400, Matthew R Welland wrote:
> > 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

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.

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

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

$ 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

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

So what happens when "originalname.host_where_modified.unique" already
exists? It is much easier to use the part of the namespace that
definitely hasn't been used yet, i.e. treat the file in conflict as a
directory and show the various versions in that directory.

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

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

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

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

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.

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

Jan