bmacintyre@watsol.waterloo.edu (Blair MacIntyre) (04/01/88)
< Eat Hot Death, LineEater >
A couple of days ago I read an article about creating a PATH: device and
using it to implement paths. There has been no more talk about it and, since
I would like to try to write one, but I don't really know anything about
DOS devices ... I've looked at the PIPE: device, and thus the coding part
seems straight forward enough. I'm just not sure what kind of messages the
device would receive for certain actions. For example, when I do a DIR
command, what kind of packets does dir send to WHERE? I realize that
I'm probably being obtuse, but if anyone out there ( at CATS for example )
could give me a little tutorial on the subject, I'd really appreciate it.
By the way, I have the original (?) AmigaDOS Technical Reference and have
read the info on DOS packets, etc. I'm just not sure who sends what where,
and how I would handle the packets, etc.
To be more specific: say I have a 'file' PATH:c which 'contains'
. vd0:c ram:c sys:c
and I get a "open path:c/fred" command, well I want to look, in order, for
. (current dir)/fred, vd0:c/fred, ram:c/fred and sys:c/fred.
So, where do I 'pass through' the packets do this action. This is the
majority of what the actions in this device would do.
Also, I'm not quite sure what to return as filehandles and locks on 'files'
for this device ... ( I'm going to look into this a bit more )
Finally, here are some ideas I have for the device:
- as the originator of this idea suggested, I'll write an addpath command
with options to manipulate the PATH: file ( through special packets, or
perhaps using read, write, seek packets ).
- various special meaning can be used in the path:
. - current dir
[dxx]: - any device that is specified (via the program) with its name in
square brackets can be taken to be that device, not what is mounted
on it currently ( ie. search whatever disk is in [DF1]: when the path
is used ) This could cause problems during use, except when
combined with the next option
(xxx) - by surrounding a path (directory, actually) name in parenthesis,
this could mean "search if it exists", so ([DF1]:c) would mean search
the c directory on the disk in df1:, if it has one.
These are just some suggestions ... any comments? I really think I could
write this if I just knew a bit more ( I want something to write in my spare
time, and this is a reasonable project ... )
HELP! ( please :-)
Blair
--
===========================================================================///=
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/====bmacintyre@watsol.waterloo.edu (Blair MacIntyre) (04/07/88)
[]
Well, I'm still playing at writing a PATH: device. Since this is my first
jump into the wonderful world of AmigaDOS devices, I have a few questions:
- From going through the AmigaDOS Technical Ref Manual, the packets I have
decided I should handle (for a read-only path device) are:
ExamineObject, ExamineNext, DiskInfo, Parent, LocateObject, FreeLock
( perhaps Duplock or Copydir or whatever as well )
The thing I'm wondering is what to do about Locks.
- I assume when I am returning a new lock I allocate it, but do I link it
into the list of Locks in the DeviceList struct ( I'm doing this from
memory from last night - I hope I have the names correct )
- do I have to keep track of the locks if I don't do the linking ( ie. do
I need to worry about it or does someone else )
- who passes these packets?
( damn, there were some other questions ... oh well - any info would be
great ).
I realize that other people are probably doing this, but I want to do it as
much for a learning experience as anything!
Thanx in advance.
Blair
--
===========================================================================///=
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/====steveb@cbmvax.UUCP (Steve Beats) (04/08/88)
In article <3903@watcgl.waterloo.edu> bmacintyre@watsol.waterloo.edu (Blair MacIntyre) writes: >Well, I'm still playing at writing a PATH: device. > - From going through the AmigaDOS Technical Ref Manual, the packets I have > decided I should handle (for a read-only path device) are: > ExamineObject, ExamineNext, DiskInfo, Parent, LocateObject, FreeLock > ( perhaps Duplock or Copydir or whatever as well ) If you want to work with WorkBench, you should support ACTION_INHIBIT and ACTION_DISK_INFO too. Workbench uses the inhibit to determine if you really are a DOS/file type handler and then uses the diskinfo packet to construct the windows gas-gauge thingy. Make sure you never return 0 for this packet because WorkBench doesn't check ther return code and gurus with a divide by 0 trap if you do this. > The thing I'm wondering is what to do about Locks. > > - I assume when I am returning a new lock I allocate it, but do I link it > into the list of Locks in the DeviceList struct ( I'm doing this from > memory from last night - I hope I have the names correct ) > - do I have to keep track of the locks if I don't do the linking ( ie. do > I need to worry about it or does someone else ) What you do with locks is pretty much up to you. Yes, you do have to allocate and free them yourself and you should keep a list of locks hanging around. If you are making a handler that will be associated with a Volume node, then there is a field in there that does just what you want. It's called dl_LockList or some such. The reason you need this list is for handling the inhibit packet. When your volume is inhibited, you should check to see if anyone has any locks on that volume, if that's the case then store all your locks in the volume node and change your DiskType to type.busy. When you receive the uninhibit packet (and therefore go through your restart code) you search for your volnode and relink the locks back into your active list (if you find the volnode of course). On the other hand, if no-one had any locks on your volume when the inhibit packet came along, then you de-allocate the volnode altogether and unlink it from DOS's list of volumes. Now when the uninhibit comes through, you'll go through the same restart code and NOT find your volume, so you'll have to manufacture a new node again. Hope this helps, Steve