Subject: Re: kern/642: lstat() returns wrong inode for symlink?
To: Charles M. Hannum <firstname.lastname@example.org>
From: Simon J. Gerraty <email@example.com>
Date: 12/16/1994 11:31:48
> 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
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?