On Tue, Jan 22, 2013 at 10:03:54PM -0600, Nevin Liber wrote: strncpy() was introduced in 7th Edition Unix. From a quick perusal through the V7 source code, these files used strncpy(): usr/src/cmd/ranlib.c strncpy(firstname, arp.ar_name, 14); usr/src/cmd/login.c #define SCPYN(a, b) strncpy(a, b, sizeof(a)) usr/src/cmd/expr.y strncpy(Mstring[0], p, num); usr/src/cmd/atrun.c strncpy(file, dirent.d_name, DIRSIZ); usr/src/cmd/ed.c strncpy(buf, keyp, 8); usr/src/cmd/mkdir.c strncpy(pname, d, slash); usr/src/cmd/xsend/lib.c strncpy(buf, s, 10); usr/src/cmd/crypt.c strncpy(buf, pw, 8); Only two of these (ranlib.c and atrun.c) appear to be specifically related to the 14-byte filename limit in V7. So I'd say that strncpy() wasn't introduced solely to deal with 14-byte filenames. Cheers, Warren

Nevin/Warren, RE: strncpy being related the DIRSIZ I do not think so, certainly not my memory of programming at the time. Back then, many other languages I was using such as SAIL and some of the Algol family had similarly named functions. I wish he were still with us to ask, but I really think that when Dennis rewrote the V5/V6 "portable C library" into what would become stdio and friends, adding the str*.c family was natural - all the other cool kids had one and it was just a convenient function when we all were writing code for C to have it also. This is pre "white book" (aka V5 & 6) but I have definite memories of the late Ted Kowalski teaching me what function libraries that were available for C. One of my first programs (after helping Ted with fsck) was rewriting a SAIL based 6502 assembler in C and needing string functions. I have distinct memory of b*tching to Ted about having to write my own string functions. By the mid-late 70s a number of "ctools"or "c libraries" would appear from UCB, CMU, MIT et al with many of the same basic functions just with slightly different parameters. Go look in the old USENIX tapes, you should see the same stuff getting recreated in many places. Clem On Tue, Jan 22, 2013 at 11:03 PM, Nevin Liber <nevin(a)eviloverlord.com>wrote:

I also second/support Ron's and uh Clem's view. In addition to zeroing out the inumber field, "removing" a file decremented the reference count in the i-node causing it to be freed (not cleared) when the reference count went to zero. There was no strncpy() in the kernel. Was there a strcpy() (other than a macro) in the kernel?? Long live movtuc. Begin forwarded message:

Decrementing the reference count in the inode also cleared an allocated bit in the flags (unless it was held open after deleted). It also added it to an ersatz-free list of 100 entries, but unlike the disk freespace, that didn't have a provision to link to more entries. After the inode freetable was exhausted, the inodes were scanned to find more free ones to replenish the list. The original v6 filesystem code wasn't very transaction safe. When the machine crashed, you can almost count on a file in the process of deletion having either a mismatched number of appearances in directories versus the reference count in the inode. The program "dcheck" was run to reconcile these. Of course, dcheck only reported the errors. Fixing them was more fun (especially since fsdb was yet to be written). Any files that were open but deleted would be left allocated with 0-0 link count and references. A program "clri" would zero out the entire inode for these files to fix that. Of course, that's a bit brute force (and hard to reverse if you screwed up and did the wrong one). We rewrote it to only reset the allocated bit. The kernel didn't have any string functions either. Namei (the function that handles mapping file names to inodes) just used char*'s to traverse, compare, and copy the strings. The code that handled the arguments for exec did the same. m45.s where many assembler utility functions lived had some block copying (although they are not heavily used by the C code which just as soon would copy things with loops) but nothing that knew anything about strings. On Jan 23, 2013, at 10:24 AM, Armando Stettner wrote:

On Wed, Jan 23, 2013 at 2:33 PM, Ronald Natalie <ron(a)ronnatalie.com> wrote: Tanks Ron - that makes sense. As I said, there were functions like that in other languages, plus their was beginning to be a number of library toolkits for C that people were cons-ing up in that timeframe --> particularly by stripping helper routines from other programs. Horton & Joy's termcap and eventually curses came to live that way. I just did a little searching of my own code archives and sure enough I found a file called support.c that has the functions len, copy and comp in it, which I must have used pre-V7 {code's ugly too - so it was clearly early C for me - I was still fighting the one-true-brace-style having come over from SAIL, Algol and BLISS}. Clem

Not to put too fine a point on it, Kirk's filesystem does not show up in the mainstream outside of Berkeley until 4.2BSD IIRC mid 1984. 4.1 was still based on the V7/TSS file systems [inside UCB we had 4.1A, 4.1B, 4.1C - although if my memory serves me 4.1C was semi-available - I know I took it Masscomp, SUN had it, and Armando you must have had it at DEC]. Anyway, the post 4.1 BSD system was when Fast File systems and Berkeley directory system calls were added, to make some of the operations atomic and the user space code more portable. Henry Spencer's famous quip in the early 1980s: *"**4.2BSD does everything UNIX does, only differently."* * * Looking back on it, ideas like the VFS layer would take a few years more. But without moving the directory specifics out of user space code like it was V7 and earlier, it would have been hard to create something as clean as VFS. On Wed, Jan 23, 2013 at 5:43 PM, Mary Ann Horton <mah(a)mhorton.net> wrote: