>> 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).
> I'm missing something here -- is there a rational reason for having
> mucked with the symlink file type?

IMO no.  I always assumed it was done for efficiency reasons; recently
I saw a message here that indicated it was done for compatability with
severely braindead systems.

> 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

Obviously, if symlinks don't have inodes, you can't hardlink to a
symlink.

Currently under NetBSD, it doesn't appear to be possible to hardlink to
a symlink (short, of course, of patching the raw filesystem images);
link(2) insists on following links named by its first argument, linking
to the linked-to object if it exists, or returning ENOENT if not.

I agree with your apparent position, that this change (making symlinks
pseudo-unowned objects) is not worth the trouble it brings and it
should be backed out.  Another patch for my private patch tree....

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu