Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!necntc!dandelion!ulowell!page
From: page@ulowell.cs.ulowell.edu (Bob Page)
Newsgroups: comp.sys.amiga
Subject: File System suggestions
Message-ID: <2086@ulowell.cs.ulowell.edu>
Date: Wed, 2-Dec-87 15:00:48 EST
Article-I.D.: ulowell.2086
Posted: Wed Dec  2 15:00:48 1987
Date-Received: Sun, 6-Dec-87 07:42:11 EST
Reply-To: page@swan.ulowell.edu (Bob Page)
Organization: University of Lowell, Computer Science Dept.
Lines: 61

I realize this is too late for the NewFS, since it has been in beta
for a while, but here are some suggestions for a future version
of the FS.

First is file truncation.  This can be done today with no sweat, but
it requires a Truncate() routine be part of DOS.  If I posted a
Truncate() routine to the net today, it might not work with the newFS,
and I'd like to keep everything working OK.  So, I guess this is a
suggestion to put a Truncate() in the dos.library.

Second is 'file links'.  Links allow you to have more than one name
for an individual file (No flames about necessity; people who don't
use multitasking don't think it's needed either).  There are some
unused and redundant longwords in the file header, how about claiming
one (or maybe the high byte of the protection longword) for a link
count?  Here are two ways to get the added functionality.  I favor
the first approach:

1.	- create a new file subtype called ST.LINK, and have it point
	BACK at an ST.FILE (as if the 'file' were a parent).  The file
	header has a longword that points to a link map, which is
	another filetype like the LIST type that contains pointers to
	all the links, and to another link map if more are needed.
	- deleting a 'link' only deletes the link from the link map.
	Deleting the 'file' will really delete a link from the link
	map, and rename the file header to the name of the link that
	you just deleted.  Pretty slick, eh?  You'll also have to
	change the parent dir's hash table .. rehash it and put the
	block number in a new place (if the link and file are in the
	same directory), or delete the old value and install a new
	on in the 'new' parent directory.  Pretty ugly, eh?  Of course
	deleting a file without a link map means it has no links;
	you delete it just like you do now.

2.	- clone an existing file header, change the name, modify the
	parent's hash table, and increase the link count on all headers
	that point to the data.
	- a change to Delete() so it looks at the link count
	in the file header.  If the link count is >1, it will delete
	the file header and decrement the link count on all headers that
	point to the data.  For link counts of 1, just do the normal
	Delete(). 
	- change other FS commands (like setting file protection,
	changing date stamps, hash tables, etc) to do it across
	all links that point to the same data.  This means either
	keeping a link map, similar to approach #1.

The first approach requires fewer changes to dos.library, and is
almost a 'soft hard' link (in UNIX terms).  The second approach
is more of a 'hard' link, but more work to implement.

Making symbolic links across file systems doesn't seem to be needed,
but links on directories (rather than just files) would be a win.

Anyway, there are two suggestions.

..Bob
-- 
Bob Page, U of Lowell CS Dept.  page@ulowell.edu  ulowell!page
"I've never liked reality all that much, but I haven't found a
better solution."		--Dave Haynie, Commodore-Amiga