Path: utzoo!mnetor!uunet!nuchat!peter From: peter@nuchat.UUCP (Peter da Silva) Newsgroups: comp.sys.amiga Subject: Re: The 1001 Paths Message-ID: <871@nuchat.UUCP> Date: 30 Mar 88 01:17:06 GMT References: <4587@garfield.UUCP> <5489@well.UUCP> <850@nuchat.UUCP> <582@imagine.PAWL.RPI.EDU> Organization: Public Access - Houston, Tx Lines: 102 Keywords: open In article <582@imagine.PAWL.RPI.EDU>, jesup@pawl11.pawl.rpi.edu (Randell E. Jesup) writes: > In article <850@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: > >1> mount PATH: > >1> Assign C: PATH:df0:c!df1:c!ram:c > >1> list c: > >Directory "c:" on Thursday 23-Mar-00 > >df0:c Dir rwed Tuesday 06:19:29 > >df1:c Dir rwed Tuesday 06:19:29 > >ram:c Dir rwed Tuesday 06:19:29 > >3 directories - 1 block used > >1> assign > >... > >c PATH:df0:c!df1:c!ram:c > >... > >1> Assign include: PATH:df0:include!vd0:include!Aztec:include > >1> set INCLUDE=include: OK, let me answer your immediate questions, and then advance my fantasy. > 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 be to refuse the packet, and have open return an error. > What does one get back when one Examine()s the result of Lock("c:",...)? > Or when one ExNext()s it? You'll get "C:" the first time, with some semi-reasonable FIB. Afterwards you'll get the result of sending an Examine packet to each element of the PATH: name. > Sorry, I'm afraid this will remain a fantasy. Why not just use shell > variables? Because dPaint won't find them. > List won't find them, but then again list wouldn't produce the > output you showed anyway. Sure it will, if Examine and ExNext work the way I described above. > It would be twit to write a routine to a) get the shell var, b) try to open > the file in each of the directories in turn. If you do, then post it to > the net (if it's done nicely.) Sorry, won't do what *I* want. One of these days I might implement PATH:... But I have been convinced that the behaviour should be: 1> mount PATH: 1> Assign C: PATH:df0:c!df1:c!ram:c 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 ... ... 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 ... ... c:copy 8128 rwed Future 14:19:14 c:cd 496 rwed Future 14:19:17 c:list 8440 rwed Future 14:19:16 ... ... 247 files - 2700 blocks used 1> assign ... c PATH:df0:c!df1:c!ram:c ... 1> Assign include: PATH:df0:include!vd0:include!Aztec: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. But if you really want this feature: a) writes to that one. b) writes to the first it finds. c) writes to the first directory. This isn't as safe, but so long as it's consistent... > 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. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.