> #: 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.

Bzzt.  First: VMS, er make that "OpenVMS", certainly does not have inodes,
or any such similar nonsense; I don't know how they do symbolic links (if
at all), but I'll bet it's through some perversion of the Logical Names
facility, which I think would be unlikely to have a file owner attached
to them.  (Anyone who has used VMS more recently than version 2 should feel
free to jump in and update me. :-)

Second, MS-DOG does not have a "node" based filesystem in the UNIX sense;
its files follow the classic model of a file object being the name, attributes,
and pointers to data all rolled together:

/*
 * Structure of a dos directory entry.
 */
struct direntry {
	u_int8_t	deName[8];	/* filename, blank filled */
#define	SLOT_EMPTY	0x00		/* slot has never been used */
#define	SLOT_E5		0x05		/* the real value is 0xe5 */
#define	SLOT_DELETED	0xe5		/* file in this slot deleted */
	u_int8_t	deExtension[3];	/* extension, blank filled */
	u_int8_t	deAttributes;	/* file attributes */
#define	ATTR_NORMAL	0x00		/* normal file */
#define	ATTR_READONLY	0x01		/* file is readonly */
#define	ATTR_HIDDEN	0x02		/* file is hidden */
#define	ATTR_SYSTEM	0x04		/* file is a system file */
#define	ATTR_VOLUME	0x08		/* entry is a volume label */
#define	ATTR_DIRECTORY	0x10		/* entry is a directory name */
#define	ATTR_ARCHIVE	0x20		/* file is new or modified */
	u_int8_t	deReserved[10];	/* reserved */
	u_int8_t	deTime[2];	/* create/last update time */
	u_int8_t	deDate[2];	/* create/last update date */
	u_int8_t	deStartCluster[2]; /* starting cluster of file */
	u_int8_t	deFileSize[4];	/* size of file in bytes */
};

Note what happens when you try to add a "hard link" on an MS-DOS filesystem.
Of course, and MS-DOS symbolic link would most naturally be a full-fledged
file, like the classic UNIX symbolic link.

Personally, I question the wisdom of hairing up directory structures any
further[*], for the dubious desire to match a misfeature of aged operating
systems ("VMS: System Software For The Sixties", for the amusement of any
of you who saw the old VAXitechture manuals...), but symbolic links sure
don't make very effective use of inode data.  If it weren't for the "sticky
directory" bit (invented chiefly to keep bored undergraduates from beating
on each other), and for nosy system administrators, they wouldn't need the
uid at all.  Still, I think the savings of a direct symlink facility (a little
diskspace, a little speed) are pretty minimal, and given disk sizes and cache
sizes nowadays, negligible.


[*] But if you really can't resist doing so, long ago I dreamed up this
marvelous scheme for hashing directory entry names in a way that would be
compatible with existing code which read directory entries directly; I
suppose this is less of a problem nowadays, what with getdirentries() being
the Official Way To Do It...