#: From kstailey@owl.dol-esa.gov Fri Jul 28 10:59:14 1995
#: Posted-Date: Fri, 28 Jul 1995 13:58:09 -0400
#: Date: Fri, 28 Jul 1995 13:58:09 -0400
#: From: Kenneth Stailey <kstailey@owl.dol-esa.gov>
#: To: greywolf@tomcat.vas.viewlogic.com
#: Cc: mouse@Collatz.McRCIM.McGill.EDU, current-users@NetBSD.ORG
#: Subject: Re:  Symlink ownership
#: 
#: > Personally, I still think that Yet Another Type of Directory Entry is
#: > a worse abomination than Yet Another Type of File.  POSIX blew it in
#: > this respect:  If you decide to change directory structure from what it
#: > is currently, all you do is add overhead.
#: 
#: They must have wanted compatbility with non-node-based filesystems on
#: other OS's.

But even this doesn't make sense.   BSD since 4.3 has been vnode based,
with some sort of filesystem switch or some such to facilitate talking
to other filesystem types (starting off the bat with NFS).  If you don't
have nodes, you can't really do much.  Even the FAT filesystem (MS/LOSS)
seems to have a somewhat node-based filesystem, to an extent.

If symlinks are not supported in the host OS, what are you going to
do?  Force an entry?  Not bloody likely.  If they *are* supported, it's
still better to have them as inodes than as munged directory entries,
as then at least the directory parsing routines are still streamlined.
The more stuff you add to a directory entry, the longer it's going to
take to just get the information from the directory.  Anything trying
to read and sort the entries is going to suffer from a performance hit.

The fact that symlinks only need user ID, mtime* and object name data
is probably what led to the quick and hasty decision that full inodes
aren't needed for these creatures.  But there must be a better way to
do it.

[*]you need mtime to give something for a date.  Since symbolic links
are almost never modified directly (save for rename/link/unlink operations,
but are we interested in these anyway on a symlink?), just use the mtime.
Nothing modifies the mtime of a symlink, so it could even be an accurate
measure of the creation time of the link, if that were desired.

There's -- what, 128 bytes for an on-disk inode?  Take away 16 bytes
for nlink/mtime/mtime_nsec/uid, and you still have 112 bytes in which to stuff
a pathname.  If you need longer, then you stuff it into a disk block and
pay the price for overhead.  (112 bytes is just under half MAXNAMELEN,
for what it's worth...)

Of course, I looked into /sys/ufs/ufs/dinode.h and discovered:
#define shortlink di_db

which implies that this approach, more or less, is being taken anyway.

Don't break this, it's fixed -- er, don't fix this, it's not broken!

#:  I don't think that it took sticky directories into
#: account.  They have to re-think this.

Yes, they do.

Someone proposed having symlink() return EPERM if someone tries to
create it within a sticky directory.

Just had a thought.

Has anyone thought of making yet another type of inode -- like a fragnode
or a linknode?  Hear me out here:

The FFS was designed to take more advantage of disk space.  The symlink
is attempting not to use inodes.  Imagine as such:

struct linknode {
	int32_t		l_uid;
	int32_t		l_nlink;
	uint32_t	l_mtime;
	uint32_t	l_mtime_nsec;
};

That's 16 bytes.  Now if it's necessary to put the symlink name data into
the directory structure (gack), we can do this.  We create a symlink.
Zap an inode which would normally be used for a symlink.  Fragment it
into 8 linknodes.  Voila' -- you now have seven more such nodes which can
be used for other symbolic links.  At the cost of one inode.

I can see where this might get even more convoluted, but it's food for
thought.  Comments?  Am I completely off my rocker, or does this make
even a modicum of sense?  Let me know.  I think there's possibilities
with this.

				--*greywolf;


#: 
#: ~Ken
#: