>    root:188# ls -idl /sys /usr/src /src /src/sys         
>       2 lrwxr-xr-x   1 root  wheel   11 Nov 17 16:58 /sys@ -> usr/src/sys
>       2 lrwxr-xr-x   1 root  wheel    4 Nov 17 16:29 /usr/src@ -> /src
>       2 drwxr-xr-x  19 root  wheel  512 Dec  7 15:18 /src/
>    7552 drwxrwxr-x  25 root  wheel  512 Nov  7 11:32 /src/sys/
> 
>    Thus /sys and /src get the same dev/inode as the root directory!
> 
> In 4.4-Lite, symlinks appear to have the inode number and time stamps
> of the directory they're in.  This is allegedly a feature, though I'm
> starting to think it's one of the silliest changes I've seen yet.

Ah!  So the symlink data (the pointer) is in the directory entry?  
I thought they were going to still use an inode and put the data in
that....  using the directory entry is a neat idea, bound to improve
filesystem performance.

Thanks for the enlightenment, that explains both why the filesystem
appears to work, and why it seems to defy my previous experience :-)

It also gives me more confidence that the basic NFS server is not
totally flawed in its design - though it will need serious hacking to
make it work on a 4.4 based system.

And to answer the obvious question...  Why am I doing this?  

For a firewall.  I want to be able to mount the filesystems on the
external firewall on a system inside the firewall.  I want TCP based
NFS, I want strong authentication and I do not want a port mapper
running on any of these machines.  All adds up to a serious hack.  A
user-land server is an easy solution.  I _need_ it on some SunOS
machines and some HP/UX ones would be cool too.

The alternative is to port NetBSD's NFS to these machines....
Anyone done that?

--sjg