Path: utzoo!utgpu!water!watmath!watcgl!watsol!bmacintyre
From: bmacintyre@watsol.waterloo.edu (Blair MacIntyre)
Newsgroups: comp.sys.amiga
Subject: Re:  1001 paths
Message-ID: <3836@watcgl.waterloo.edu>
Date: 31 Mar 88 20:08:59 GMT
Sender: daemon@watcgl.waterloo.edu
Reply-To: bmacintyre@watsol.waterloo.edu (Blair MacIntyre)
Distribution: world
Organization: Centre for the OED, 2nd Edition
Lines: 89

In article <871@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes:
>But I have been convinced that the behaviour should be:
>
>1> mount PATH:
>1> Assign C: PATH:df0:c!df1:c!ram:c

Actually, I prefer the 
1> addpath PATH:c df0:c df1:c ram:c

for one reason:  with that above scheme, aren't you limited to having paths 
only as long as amigados filenames?

Also, another article I posted today for a few variations on the possible path
elements ...

>1> list c:
>Directory "c:" on Thursday 23-Mar-00
>Run                         2324 rwed Future    14:18:53
>Fault                       2728 rwed Future    14:18:54
>Install                     1800 rwed Future    14:18:55
>stack                        296 rwed Future    14:18:55
>... <contents of df0:c>...
>More                        8640 rwed Future    14:21:28
>viewilbm                   11472 rwed Future    14:21:30
>disksalv                   12796 rwed Future    14:21:33
>unshar                      9884 rwed Future    14:21:35
>dmp                         8008 rwed Future    14:21:36
>... <contents of df1:c>...
>c:copy                      8128 rwed Future    14:19:14
>c:cd                         496 rwed Future    14:19:17
>c:list                      8440 rwed Future    14:19:16
>... <contents of ram:c>...
>247 files - 2700 blocks used

Exactly the way it should work!  :-)

>1> assign
>...
>c               PATH:df0:c!df1:c!ram:c

or   

c               PATH:c

>1> Assign include: PATH:df0:include!vd0:include!Aztec:include

As above,
1> setpath PATH:include df0:include vd0:include Axtec:include
1> assign include PATH:include

>1> set INCLUDE=include:
>
>Let's go back and look at your problems in context of this variant...
>
>> What happens when someone opens c:filename for write if a) it exists in one
>> of the directories, b) exists in more than one, c) exists in none?
>
>The safest thing would still be to refuse the packet, and have open return
>an error, just as if it was a read-only file system.

I think I agree with this ... to dangerous:  say you have a source path so
that the compiler uses your modified files first, then the 'originals'.  
If you delete the 'modified' file twice, you could mess yourself up ...
 
>> What does one get back when one Examine()s the result of Lock("c:",...)?
>> Or when one ExNext()s it?
>
>Examine returns something that looks like a directory. ExNext returns each
>file in turn. Really, it behaves much like Matt Dillon's sample RAM: driver.

Hmmm ... where can I get the RAM: driver source ( or is it possible )?

----------------------

In another article, someone suggested some things about the PATH: driver
using an AREXX port for communication, etc ... I think this is getting to
complicated.   The device should simply be a read-read-only file system
( a suggested above ) which allows multiple paths to be scanned together.

The article did mention some important concerns, such as making sure that
the same filename is not returned more than once, etc.  The are definately
important points.  But as for all this added complication, why bother?
In this case, the KISS principle is very appropriate...  :-)

--
===========================================================================///=
Blair MacIntyre (bmacintyre@watsol.waterloo.edu) ( Long live the Amiga!! )///
"Violence is the last resort of the incompetent" - Issac Asimov       \\\///
=Have you hugged your dragon today??=(how about your SO??)=============\XX/====