Note to readers: this email contains NetBSD-relevant questions.  Read on.

>As the home page for CFS
>    http://www.crypto.com/software/
>explains that that software is nearly nine years old and unsupported,

That is, "mature, but not commercially viable".
CFS has its problems, but I think it's an okay interim measure.

>your best bet is probably to either
>1) boot from a 1.4[E-Z]*-ish stand-alone system that supports NFS
>2) Restore from backups, and then copy the files off.

Interesting suggestions, but I don't want the data to appear on
an unencrypted volume, even during a transitional period.  So
this begs the question, where do I put it?  These are only half
solutions to my problem.

>To get back on topic (which is, discussion about programs included
>with NetBSD), take a look at:
>    http://www.netbsd.org/Changes/#cgd
>which links to the man pages. CGD is presently only in -current,
>however.

I hesitate to update (esp. to netbsd-current), given that I haven't
solved the problems posed by my upgrade to NetBSD-1.5.2.  It might
well be something I'll migrate to in the future, though.  So is
rubberhose a/k/a marrutuku (c.f. www.rubberhose.org).

I was really hoping for some insight in what might have changed in NetBSD's
userland with respect to RPC so that I might be able to get CFS working.
NetBSD has had a very good record up to this point with respect to
keeping backwards compatibility.  This binary still works
(but I have no idea how to use it, and it lacks a manpage):

    # ls -l /bin/red
    -r-xr-xr-x  1 bin  bin  98304 Aug  1  1994 /bin/red

If you know a better forum for my query, as I've stated it above,
I'll gladly make it there.  But I think it is relevant here.
I'm not asking for support for CFS.  I'm asking about NetBSD userland
and what may have changed such that old nfsd-style binaries no longer
work.  I just noticed the following behavior that may help jog memories:

portmap rpcbind cfs  mount_nfs
------- ------- ---- ---------
no      yes     hang n/a
no      "-i -L" hang n/a
yes     no      runs hang
yes     yes     runs hang

Looking at the manpages for rpcbind, portmap, and rpcinfo -p, I get
the impression that rpcbind is a replacement for portmap.  Given the
above behavior, is this the kind of thing that recompilation would
fix?

I've noticed another strange phenomenon while researching this problem.
Observe the behavior of "rpcinfo -p" while rpcbind is running.
It appears as though rpcinfo is lying about that port:

# rpcbind
# rpcinfo -p
   program vers proto   port  service
    100000    4     0    111  portmapper
    100000    3     0    111  portmapper
    100000    2     0    111  portmapper
# netstat -Aan | grep -w 111
#

>Did you update both the userland
>and the kernel, and the binary that you are running has been compiled
>under 1.5.2?

Alas, I am currently unable to recompile CFS because of the following reason,
quoted here just for your information and not as a plea for you to help me:

$ gcc -O2 -DNFS_PORT_SHARING=SO_REUSEPORT -DPROTOTYPES=1 -DBSD44 -DANYPORT -DCFS_PORT=2049 -DSHORTLINKS -I/usr/local/include  -c cfs_adm.c
cfs_adm.c: In function `admproc_null_2':
cfs_adm.c:40: number of arguments doesn't match prototype
admproto.h:224: prototype declaration
cfs_adm.c: In function `admproc_attach_2':
cfs_adm.c:47: argument `rp' doesn't match prototype
admproto.h:227: prototype declaration
cfs_adm.c: In function `admproc_detach_2':
cfs_adm.c:160: argument `rp' doesn't match prototype
admproto.h:230: prototype declaration
*** Error code 1
$ cat -n cfs_adm.c | grep -3 40 | head -n 6
    37
    38  void *
    39  admproc_null_2()
    40  {
    41  }
    42
$ cat -n admproto.h | grep -B 2 admproc_null_2
   211  #ifdef __cplusplus
   212  #define ADMPROC_NULL 0
   213  extern "C" void * admproc_null_2(void *, CLIENT *);
   214  extern "C" void * admproc_null_2_svc(void *, struct svc_req *);
--
   222  #elif __STDC__
   223  #define ADMPROC_NULL 0
   224  extern  void * admproc_null_2(void *, CLIENT *);
   225  extern  void * admproc_null_2_svc(void *, struct svc_req *);
--
   233  #else /* Old Style C */
   234  #define ADMPROC_NULL 0
   235  extern  void * admproc_null_2();
   236  extern  void * admproc_null_2_svc();

Note that admproto.h is generated from admproto.x via rpcgen.

I'm not very familiar with RPC and NFS, so I'm going to go get my O'Reilly
books on these topics out of storage, but I'm concerned that there may
be changes in NetBSD's rpcgen or the RPC Run Time Environment that diverge
significantly from my (rather old) books.  I note that the CFS docs
specifically caution Linux users due to the fact that there were three
different rpcgen implementations out there at the time of writing.

But before I dive into the problem of recompiling CFS, with its attendant
question about how NetBSD's userland toolchain has changed in such a way
that it no longer compiles cfsd, I think it would be prudent to first ask
how the run time environment for RPC has changed, since I'm not sure that
recompiling CFS would necessarily solve my problems.

I hope that I have made the NetBSD angle on this clear enough that you
don't feel the need to generate more brush-off email.  At the same time,
I appreciate you having read this far.

TIA,
vax@carolina.rr.com