Path: utzoo!attcan!telly!ziebmef!mcp
From: mcp@ziebmef.uucp (Marc Plumb)
Newsgroups: comp.sys.amiga.tech
Subject: Re: yet another 1.4 request
Message-ID: <1989Jun16.151408.8382@ziebmef.uucp>
Date: 16 Jun 89 19:14:06 GMT
References: <0933.AA0933@caleb>
Reply-To: mcp@ziebmef.UUCP (Colin Plumb)
Organization: Ziebmef Public Access Unix, Toronto, Ontario
Lines: 31

In article <0933.AA0933@caleb> jdp@caleb.UUCP (Jim Pritchett) writes:
>This is yet another 1.4 request.  Could file links be added?  How difficult
>would this be?

I know this is being worked on, both hard and soft, but there are tricky bits.
Suppose /bin/vi and /bin/ex are links to the same file.  I Lock() vi, then
Examine() the lock.  Which name gets returned?  Does the file comment
go with the name (so vi and ex could have different comments) or the file
(so they'd have the same)?  Also, there is the bit that's nasty for
directory-scanning speed, in that you now have to store the name in one
place and the file-specific information (size, date, etc.) in another,
and read both places when returning a FileInfoBlock.

Then there's the business of allowing files with no links, and do you allow
directories with multiple links, etc.

I have a solution to some of these problems, by saying that a Lock is not
a file, it's a pathname to a file.  You can move the path (so /bin/vi
can get moved to /usr/ucb/vi) without breaking it, and Examine() and
ParentDir() will tell you that's the name of the current lock, without
bothering you with /bin/ex.  A file can have no links, if it's only
referenced through a FileHandle and not a Lock, and it will do the
normal Unix thing of being deleted on close.

BTW, all this would require serious hacking to the Commodore-supplied file
systems.  I think they'd end up being rewritten.

I've asked before, but does anyone here have any opinions on The Right Way
to provide these features?
-- 
	-Colin Plumb