Now that I've gotten to the point where I'm not restarting (and often
enough, reinitializing) venus on a daily basis, I'm starting to recognize
very changed behavior from the client.[1]  For example, cfs lv doesn't
seem to work without authorization:

------------------------------------------------------------------------
bash-2.05b$ cfs lv /coda
  Status of volume 0xff000001 (4278190081) named "CodaRoot"
  Volume type is Backup
  Connection State is Connected
  Minimum quota is 0, maximum quota is unlimited
  Current blocks used are 0
  The partition has 0 blocks available out of 0
  Write-back is disabled

bash-2.05b$ cfs lv /coda/tleepslib.sk.tsukuba.ac.jp/
/coda/tleepslib.sk.tsukuba.ac.jp/: Resource temporarily unavailable

bash-2.05b$ cfs lv /coda/tleepslib.sk.tsukuba.ac.jp/Software
/coda/tleepslib.sk.tsukuba.ac.jp/Software: Operation not permitted

bash-2.05b$ tail -3 /var/log/coda/venus.err
10:00:42 Coda token for user 1000 has expired
10:44:05 tleepslib.sk.tsukuba.ac.jp nak'ed
10:44:14 Coda token for user 1000 has been discarded

bash-2.05b$ clog codakami
username: codakami_at_tleepslib.sk.tsukuba.ac.jp
Password: 

bash-2.05b$ cfs lv /coda/tleepslib.sk.tsukuba.ac.jp 
  Status of volume 0x7f000014 (2130706452) named "coda:root"
  Volume type is ReadWrite
  Connection State is Connected
  Minimum quota is 0, maximum quota is unlimited
  Current blocks used are 248943
  The partition has 51192 blocks available out of 727892
  Write-back is disabled

bash-2.05b$ cfs lv /coda/tleepslib.sk.tsukuba.ac.jp/Software
  Status of volume 0x7f000014 (2130706452) named "coda:root"
  Volume type is ReadWrite
  Connection State is Connected
  Minimum quota is 0, maximum quota is unlimited
  Current blocks used are 248943
  The partition has 51192 blocks available out of 727892
  Write-back is disabled

bash-2.05b$ 
------------------------------------------------------------------------

And hoarding for disconnected operation seems to fail often; I end up
with the realm as a dangling symlink.  This is really distressing....

I thought maybe I need to do "hoard add /coda", but then I get

  *** missing/invalid ***  /coda/

from hoard walk, although hoard list shows the distinguished CodaRoot
object.  My HoardList file currently looks somthing like this:

------------------------------------------------------------------------
clear
add /coda                              1000
add /coda/realm                        1000
add /coda/realm/Teach                  1000:c+
add /coda/realm/Teach/thisterm         1000:d+
add /coda/realm/Teach/lastterm          500:d+
add /coda/realm/XEmacs                  100:d+
------------------------------------------------------------------------

(where "realm" is abbreviated for presentation, really there's an FQDN
there).  The idea is that the root contains a lot of cruft I don't
want (all my directory names are capitalized, so it used to be
convenient to propagate scratch files, such as .debs, with "cp scratch
/coda/", and Teach contains a fairly long history (three years of
class notes and records), but I only want the current and previous
term hoarded for disconnected work.

Is this the right way to accomplish that configuration?


Footnotes: 
[1]  So far---three days' experience---the patch to discard rather
than assert on missing objects you sent me for vol_cml.cc seems to be
working.  Ie, venus continues on repairable errors.  I had one
local/global conflict on a directory (in the XEmacs CVS tree) the
first day after installing the patched venus, but I was able to
resolve that with repair.  What exactly is the relationship between
"cfs beginrepair" and the "repair" utility?

I haven't looked at the logs yet to see if venus hit any of the snags
that were taking it down before.

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