Coda File System

Re: doc problems

From: Jan Harkes <>
Date: Thu, 13 May 2004 14:57:11 -0400
On Thu, May 13, 2004 at 12:56:07PM -0400, wrote:
> venus-setup uses some program called codaconfedit. It is not a script; it's a
> binary. There is no man page for it in the man-page tarball. What is this
> thing? Does its existence imply that I should fear to hand-edit
> /etc/coda/venus.conf?

No, it started off as a script, but had a dependency on 'ed' and I believe
at the time this was a non-standard binary in the cygwin install. Over
time it also got more and more functionality, so a small C-program ended
up being simpler to maintain.

Hand editing should be fine, we just needed something for the setup

> clog has a detailed useage msg, which it prints out on stderr when it is
> unhappy. But it's all lies:
>     ; clog -help
>     Missing host
>     Usage clog [-q] [-test] [-h authserver] [{-kerberos4,-kerberos5,-coda}]
> 	    [-tofile <file>] [-fromfile <file>]
> 	    [-as username] [Coda username]
> According to the man page, and this also appears to be the way it actually
> works, clog really only takes a -x switch. This is quite misleading and
> would be very easy to fix.

Never heard of option '-x'. 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>.

btw. you typed 'clog -help' instead of '--help', so it didn't match the
-h for a usage message and dropped through to the -h<anything> test,
assumed you tried to do -host <authserver>, but there was no host given.

> I also note that coda tools are distinguished by their pretty consistently
> missing the standard --help switch. It would sure be handy to have it.

Standard? That is a GNUism. As far as I know, the standard getopt
doesn't even parse the --long options. A lot of the Coda binaries are
based on stuff that was written somewhere in the 1980's. Coda was
originally developed on MachOS and NetBSD systems, which do not use the
GNU libc.

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

> Finally, it seems to me that having "cfs la" error out with a msg about timing
> out when the true problem is that the client is in disconnected operation is
> an extremely unfriendly and misleading error msg. Is it impossible to have it
> report that the client's in disconnected op? (The answer may be "yes;" I'm
> pretty much a novice here.) A better report would save a lot of user
> confusion.

Probably, whenever the RPC layer times out we're always disconnected, so
the ETIMEDOUT error can probably be caught and replaced by some other

Received on 2004-05-13 14:59:46