Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!super!udel!princeton!njin!rutgers!mailrus!purdue!decwrl!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: PATH: and (pseudo)announcement of RDF:
Message-ID: <8810261744.AA28807@cory.Berkeley.EDU>
Date: 26 Oct 88 17:44:32 GMT
Article-I.D.: cory.8810261744.AA28807
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 29

U211344@HNYKUN11.BITNET (Olaf 'Rhialto' Seibert) Writes:
:Now we are talking about PATH: anyway... did everybody see that the
:code to be added to Matt's original RAM disk is fairly minimal??
:I would like to suggest that code like this could be added to the
:*normal* file system in a next release, using one of those protection
:bits.
:In fact, if you have the code for a search-path-file, you almost have
:symbolic links. These are even slightly simpler.
:Isn't there a lot of room left in the file header block? That space
:could also be used in the future for some useful information.

	I agree, softlinks are a must!  I also like the directory
concentrator PATH: gives us ... all that needs to be added is a way
to be able to DIR it (and get *all* the directories).

	For softlinks, it seems pretty obvious that the way to implement
them is to simply add a protection bit.

	For sof links, the comment field would contain the path of the
link.  This is relatively painless to implement and works along the same
lines as PATH: (but even easier!).  I suppose one could use the file
contents as the link but this is very, very wastefull of time and space.

	As an example, to make my Makefile's more independant I can always
write object files to the local directory 't' instead of T: or RAM: or VD0:..
this would be (A) A real directory if I want the objects to stick around on
my HD (survive resets), or (B) A softlink to RAM: or VD0: or whatever...

				-Matt