OK, I've resolved my two big issues (lack of time and ancient Linux
kernel), and want to get back to making Coda a little less annoying to
use.

Usage pattern: one server, one client most of the time (client and
server on same machine), plus a couple of occasionally connected
clients.  Never more than one client active at once.  Problem
scenario: CVS (remote repository) workspaces, on CVS update regularly
get conflicts which repair cannot resolve (even discardalllocal often
results in a client hang or crash).  Evidently what CVS does is
recreate all the directories in the tree, even those you aren't
currently using, if you have update -dP.  So this involves a lot
(100s) of creating sub/subsub/CVS/{Entries,Root,Repository} stuff that
is just going to get thrown away in the end.  Typically a conflict
occurs somewhere in that process.

cfs fr always returns

bash-2.05b$ cfs fr .
VIOC_SYNCCACHE: Invalid argument
  VIOC_SYNCCACHE returns -1

Any repair operation seems to hang forever.

Coda version: 5.3.20, from CVS not too long after release of 5.3.20.
lwp, rvm, rpc2 from the same release.

Debian GNU/Linux (sid), glibc 2.3.1, gcc 2.95.4, binutils 2.13.90.0.16

Linux kernel 2.2.18 (consider the verbal description above to apply to
this).
and 2.4.20 (locally configured but no patches).  Ext2 fs, RVM in files
for both server and client, vanilla .confs, RVM sizes from menu.
2.4.20 seems a little more robust; the conflicts occur but (at least
in the two days since I installed 21.4.20) venus doesn't crash.

The following logs resulted from "patch -R -p 0 <patch-12-20-2002",
which patches about 150 files.  It hung on src/realpath.c (which is
the 131st), leaving the directory src in conflict.  The very end of
the logs I was fooling around with repair, and eventually had to kill
-9 the repair tool (which seems to take forever to do its work even if
it succeeds, which is quite rare except for discardalllocal, BTW).



(Why doesn't coda.log contain the information from coda.err?)

I can probably reproduce this behavior at will, so let me know what
you need to see.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.