#: From owner-current-users@NetBSD.ORG Tue Jul 25 08:25:23 1995
#: Date: Tue, 25 Jul 1995 06:10:25 -0400
#: From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
#: To: current-users@NetBSD.ORG
#: Subject: Re:  Symlink ownership
#: 
#: > there is a long-standing bug in NetBSD that I think now is ripe for
#: > at least a temporary fix until this can be done "right".
#: 
#: This is really a design bug, not a code bug.  Perhaps one could call it
#: an ill-thought-out feature rather than a bug.
#: 
#: > The problem is "who should be the owner of a symlink"?  Currently the
#: > owner is set to the owner of the directory where the symlink is
#: > created.
#: 
#: Not quite.  The idea is to present symlinks as objects which don't have
#: owners (which is currently not true; this is preparation for a day on
#: which it may be).  But _something_ has to go into the st_uid and st_gid
#: fields of the struct stat; the choice was to copy the ownership of the
#: containing directory.

I'm missing something here -- is there a rational reason for having mucked
with the symlink file type?

What does it really buy in the long run for symlinks to be a file type
which is detached from the filesystem?

Owner of a symlink is no biggy -- it should be the person who created the
damned thing (for tracking purposes -- it would be really nice to type
'ls -l' and see who created it).

The only other thing of consequence in a symlink would be link count.
And, of course, the thing the link points to.

Pyramid handled this by keeping the name of the object in the space usually
reserved for the direct and indirect block pointers.  If that worked,
there were no blocks claimed by the inode and so it took up no space.
If the object name were too long (>52 bytes) then the link would have to
assume a block for its name.

This was not necessarily a bad thing.

I have another scenario for you.  If symlinks aren't supposed to have inodes
(this is what I am gathering from the direction the discussion is going),
then what happens if you make a hard link to a symlink (which, while a bit
roundabout, is not out of the question)...?

#: 
#: > This causes problems with directories which have the sticky bit
#: > turned on (prominent example: /tmp), and opens up the ability for
#: > twarthing disk quota systems [...]
#: 
#: Right you are.  But it really is a design bug, not a code bug, since
#: the code is doing what it's intended to do.

It's a *major* design bug, and it really should have been thought out
a bit more before its implementation.

#: 
#: > So, please, can a (temporary?) fix for this problem be implemented?
#: 
#: Would you care to suggest one?  So far, the only fix I've heard is to
#: go back to the old way of symlinks having owners and such same as
#: anything else in the filesystem.  A couple of people have, as you
#: noticed, submitted fixes that do that.  While I am not in a position to
#: speak authoritatively, I suspect that core is not doing this because
#: they want to be able to reimplement symlinks as a new kind of directory
#: entry, in which case they would not have inodes and truly would _not_
#: have owners...unless you count the owner of the enclosing directory,
#: which (surprise surprise :-) is the owner the current code gives them.

Here again, what happens if you want to (for whatever oddball off the wall
reason) make a hard link to a symlink?  Yes, it's silly; yes, it's probably
redundant, but it's not out of the question that it would happen.

(I need to look at the symlink code.)  If you're not storing the symlink
object data in a data block, and you're trying to detach its inode (another
good place for the object data), where is it being stored?  If you're storing
it in the directory itself, what is this buying you?  Wherever you put the
data is irrelevent -- it's still a disk access to get the information, only
now, we have a brand new directory entry type which means the directories
are going to get mucked with and convoluted.  I wonder if it'll stop there.

Outside of disk space considerations, what good is this symlink conversion
going to do?  i.e. please, someone, clue me in as I am getting the impression
that I am *REALLY* missing something.

I keep wanting to ask what the difference is between dissociating a symlink
and dissociating a device, since devices certainly don't need disk blocks,
but I keep answering my own question (no flames on that, please).

I still wonder about 'ls' not working right when 'ls -l'-ing a directory,
but that probably won't change either (go back about a year to see what I
mean).

					--*greywolf;

#: 
#: 					der Mouse
#: 
#: 			    mouse@collatz.mcrcim.mcgill.edu
#: