When I search the web for information about the origin of UNIX symbolic links, I see "Symbolic links were first introduced into Unix with 4.1c-BSD". But when I go to fact check that, it doesn't appear to be true. What I see instead is that Dennis Ritchie modified nami.c on Eighth Edition research UNIX (A.K.A "version 8" or just "v8") and his modifications to nami.c were added to "4.1BSD".
I put "4.1BSD" in quotes because the CSRG appears to have put more work into release engineering after they won their DARPA contract. After winning the contract they started adding "point release versions", e.g. 4.1a, 4.1b and 4.1c. Before that they just cut release tapes from a "staging" file system that received updates instead of a master tape, which resulted in "4.1BSD du jour". See Mike Haertel's reconstruction of the September 1, 1981 release of 4.1BSD for details about this.
The presence or absence of symlinks in BSD can be determined by the number of arguments that the nami() function has. A third argument was added to nami() that indicates path name traversal is following a symlink, nami(func, flags)
vs. nami(func, flags, follow)
SCCS version control updates certain tokens by replacing them with the version number and date of the check-in to the SCCS file. The tokens are added to comments in the source code files so the version of the file can be identified that way. The CSRG ISO is the one sold by Marshall Kirk McKusick. I use md5 hashes to show that the content matches.
4.0BSD (CSRG ISO) Nov 9, 1980 4.0/usr/src/sys/sys/nami.c does not have symbolic links
/* nami.c 4.2 11/9/80 */
978150343fb19f4cac166487bc576144 4.0/usr/src/sys/sys/nami.c
4.1BSD reconstructed September 1, 1981 does not have symbolic links
/* nami.c 4.5 81/03/09 */
1ba9cdcbaed3a418aa62b1212425ec40 nami.c
4.1BSD (4.1.snap from CSRG ISO) May 17, 1981 4.1.snap/sys/sys/nami.c does not have symbolic links
/* nami.c 4.5 81/03/09 */
1ba9cdcbaed3a418aa62b1212425ec40 4.1.snap/sys/sys/nami.c
http://bitsavers.trailing-edge.com/bits/UCB_CSRG/4.1_BSD_19810710.zip
/* nami.c 4.5 81/03/09 */
1ba9cdcbaed3a418aa62b1212425ec40 nami.c
At some point in the 4.1BSD series, file and directory names were reorganized. nami.c
became ufs_nami.c
. The limitations of SCCS version control do not allow changes to file names to be seen.
Eight Edition UNIX (no official release, not everything has SCCS IDs) has symlinks usr/sys/sys/nami.c; it is a hybrid of having both symlinks and the old name "nami.c", pre "ufs_nami.c". I doubt that Bell Labs would undo the large number of file and directory name changes in 4.1c. I don't have the source code to the 4.1c kernel, it isn't on the CSRG ISO.
I checked three different V8 archives:
- V8 source code in 9legacy
- V8 source code in TUHS UNIX archive
- V8 source code in AAP's Squoze website
The first two appear to be identical, while the third one has the same source code as the other two, only the kernel has been configured for a VAX/11-750 instead of a VAX/11-780.
The CSRG ISO has an SCCS repository file: 4.1c.1/sys/sys/SCCS/s.ufs_nami.c
In that file the first commit that contains symlinks: nami(func, flags, follow)
is version 4.9. The commit comment says: dmr's nami. "dmr" are Dennis Ritchie's initials and his UNIX account name was always "dmr".
D 4.9 82/02/26 16:43:04 wnj 13 12 00190/00141/00089
MRs:
COMMENTS:
dmr's nami
The contents of the commit:
$ sccsdiff -u -r 4.9 -r 4.10 s.ufs_nami.c
------- ufs_nami.c -------
--- /tmp/geta852 1981-11-08 16:55:52.529794597 -0500
+++ /tmp/getb852 1982-02-26 16:43:04.533404771 -0500
@@ -11,7 +11,7 @@
/*
* Convert a pathname into a pointer to
- * an inode. Note that the inode is locked.
+ * a locked inode.
*
* func = function called to get next char of name
* &uchar if name is in user space
@@ -19,190 +19,221 @@
* flag = 0 if name is sought
* 1 if name is to be created
* 2 if name is to be deleted
+ * follow = 1 if links are to be followed at the end of the name
*/
struct inode *
-namei(func, flag)
- int (*func)();
+namei(func, flag, follow)
+ int (*func)(), flag, follow;
{
[...truncated for brevity...]
The next commit, less than 24 hours later contains (mostly additional) code, which is not in the V8 nami.c, to deal with some aspects of parent directories, etc.
D 4.10 82/02/27 14:54:34 wnj 14 13 00013/00006/00273
MRs:
COMMENTS:
symbolic links
I doubt Dennis Ritchie would have removed that code from V8. In 1987 he wrote a reply to a thread on USNET about symbolic link parent directory handling. ...the BSD and V8 conventions for dealing with symbolic links are well-chosen....
Subsequent BSD versions on the CSRG ISO show that by 4.1c an additional 26 commits occurred from February 27, 1982 to February 10, 1983. This casts doubt on the statements that symlinks were first in 4.1cBSD instead of an earlier version.
4.1c.1BSD CSRG ISO - file modification timestamp May 16, 1983 - 4.1c.1/sys/sys/ufs_nami.c
/* ufs_nami.c 4.35 83/02/10 */
451cb3ea57422cf356d48c853cb2321d ufs_nami.c
4.1c.2BSD CSRG ISO - file modification timestamp Feb 10, 1983 - 4.1c.2/a/sys/sys/ufs_nami.c
/* ufs_nami.c 4.35 83/02/10 */
451cb3ea57422cf356d48c853cb2321d ufs_nami.c
Is anyone able to add anything more to this? I welcome any rebuttals, more supporting evidence, etc.
VM.snapshot.2/vax/conf/conf.old/MONET
on the CSRG ISO contains Datakit options. digitalassets.lib.berkeley.edu/techreports/ucb/text/…select(2)
system call appear to be a shared idea. inbox.vuxu.org/tuhs/…