Path: utzoo!mnetor!uunet!cbmvax!steveb
From: steveb@cbmvax.UUCP (Steve Beats)
Newsgroups: comp.sys.amiga
Subject: Re: PATH: device
Message-ID: <3594@cbmvax.UUCP>
Date: 8 Apr 88 13:45:25 GMT
References: <3903@watcgl.waterloo.edu>
Reply-To: steveb@cbmvax.UUCP (Steve Beats)
Organization: Commodore Technology, West Chester, PA
Lines: 39

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