On Thu, May 13, 2004 at 06:15:47PM -0400, shivers_at_cc.gatech.edu wrote:
>    Hand editing should be fine, we just needed something for the setup
>    scripts.
> 
> Ahh. Thanks. The reason I asked is that for some reason I don't understand,
> the debian package on coda.cs.cmu.edu doesn't install venus-setup. If you
> hose yourself and want to reset your setup by means of a venus-setup, you're
> out of luck. (Perhaps there's a way to do this with the deb package machinery?
> I am not a debian expert.) But the coda documentation is done in terms of
> venus-setup, so it seems like it would be a good thing for the deb pkg to
> keep the venus-setup script, no?

All debian packages that use debconf for their configuration parameters
can be reconfigured by running,

    dpkg-reconfigure <package name> (i.e. coda-client)

Venus-setup really doesn't do all that much anymore, it checks some
things like possibly missing /etc/services entries and whether the
/dev/cfs0 kernel device is available. The only parameters that it
modifies are the cache size and the not-really-necessary default realm.

>   - If you try, for variety, "-h<host>", it just appears to ignore the switch:
>     % clog -htestserver.coda.cs.cmu.edu shivers
>     username: shivers_at_lambda.csail.mit.edu
> Any way you slice it, the -h switch handling of clog is way broken.
> 
> As for all these other undocumented switches in clog -- they are mystery
> switches. Could they be described in the man page?
> 
>    Any case, looking at the source it looks like -h is used for the help
>    message and -h<anything> is used to match something like -host
>    <authserver>.
> 
> Strange, because as you can see from the two examples above, that's
> not the behavior I see for the "-h<anything>" case.

Actually that would be 'clog -host testserver.coda.cs.cmu.edu', or clog
-hahaha testserver.coda.cs.cmu.edu, considering that we only test if the
option starts with an 'h' and has at least more than 2 characters.

btw. the man page that I have here seems to be just fine, I've attached
it.

>    I can't really find when exactly long options were introduced, but if I
>    can believe google, even groff didn't have them until at least April
>    2000. Ahhh, I did find it..
>        http://groups.google.com/groups?selm=9111142329.AA21815%40mole.gnu.ai.mit.edu
> 
> But here in the open-source future, it's a defacto standard & a useful
> one, and one that is very easy to make happen.

Patches are ofcourse gratefully accepted, btw. clog already has --help.

> Maybe this is a misinformed & dumb question. Can cfs distinguish between
> being in a WriteDisconnected state and being connected to a catatonic
> server? What was weird was that the server was up, functioning properly,
> my net connection was working fine, I never did anything to request the
> client go into WriteDisconnected state, but it was in that state. And

The client probably didn't like the server or network performance, when
it has to wait too long for responses it considers the connectivity
'weak' and automatically switches to write-disconnected operation. Or
when the server doesn't respond to requests for more than about 15
seconds (blocks internally on a long operation, or a network switch
reboots, or whatever) the client falls back to disconnected mode and
logs all modifications. Then when the server becomes reachable again
back we will only find out during an occasional server probe (about once
every 5 or 10 minutes) and even then continue as write-disconnected
until all pending modifications have been reintegrated.

> when I tried to look at my coda filesys, it would fail in a mysterious
> way that made it appear that the server was somehow borked. ???

Only for setacl and listacl operations, we don't do those in
disconnected or write-disconnected state. There is no use for the client
to cache an ACL because it really can't do anything with it without the
PDB database (user/group information) and when settting an ACL the user
probably wouldn't like it if the change didn't happen until a couple of
hours later because it was somewhere in the CML all this time.

Jan