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: