gm@ionic.UUCP (Greg Miller) (10/23/90)
For a current project, I'm writing a console-ish handler. However, with
the sparse documentation on them, I've come up to a problem. (For
documentation, I'm using the little stated in the back of the AmigaDos
manual, and the article(s) on file systems from a few old issues of
transactor by the Software Distillery guys.)
Here's the problem:
I have a device associated through a mountlist with my handler - let's
call it "HAN:". I need to be able to issue a NEWCLI HAN:parameters command.
I receive ACTION_FINDINPUT and ACTION_FINDOUTPUT packets fine.
(Although I don't remember which comes through first.) The first packet
contains a Lock of 0 (as I expected), and a BSTR containing the filename -
in this case, "HAN:parameters". This works fine.
Here's the problem:
When the second of the two comes through, it comes with a filename of "*",
(which I process as "current output"), and a Lock (to which, as far as I
can tell, the "*" is supposed to be relative). Where's this Lock coming
from? My handler certainly isn't creating this lock in response to any
packets. Secondly, since both the ACTION_FINDINPUT and ACTION_FINDOUTPUT
are supposed to access the same thing, how can I associate the lock to
the previous ACTION_FINDwhatever? (Is there any way I can find the handle
that I filled in during the original ACTION packet from the lock passed
to me by the second?)
Help!
- Greg
+----------------------------------------------------------------+
| A sign of mismanagement, over- | Greg Miller |
| complication and overall idiocy: | ..ames!sharkey!ionic!gm |
| | gm@ionic.uucp |
| | |
| "Designed By Committee" | |
+----------------------------------------------------------------+rhialto@cs.kun.nl (Olaf Seibert) (10/27/90)
In article <gm.3448@ionic.UUCP> gm@ionic.UUCP (Greg Miller) writes: | For a current project, I'm writing a console-ish handler. However, with | the sparse documentation on them, I've come up to a problem. (For | documentation, I'm using the little stated in the back of the AmigaDos | manual, and the article(s) on file systems from a few old issues of | transactor by the Software Distillery guys.) | | Here's the problem: | | I have a device associated through a mountlist with my handler - let's | call it "HAN:". I need to be able to issue a NEWCLI HAN:parameters command. | | I receive ACTION_FINDINPUT and ACTION_FINDOUTPUT packets fine. | (Although I don't remember which comes through first.) The first packet | contains a Lock of 0 (as I expected), and a BSTR containing the filename - | in this case, "HAN:parameters". This works fine. | | Here's the problem: | | When the second of the two comes through, it comes with a filename of "*", | (which I process as "current output"), and a Lock (to which, as far as I | can tell, the "*" is supposed to be relative). Where's this Lock coming | from? My handler certainly isn't creating this lock in response to any | packets. Secondly, since both the ACTION_FINDINPUT and ACTION_FINDOUTPUT | are supposed to access the same thing, how can I associate the lock to | the previous ACTION_FINDwhatever? (Is there any way I can find the handle | that I filled in during the original ACTION packet from the lock passed | to me by the second?) | Help! The file name * is special, and it just means "get me a duplicate of the console file". Since you normally have one HAN: process per console, it should not be too difficult to create some kind of duplicate of the filehandle that you made for the first ACTION_FINDwhatever. In fact, all filehandles that refer to that one process naturally refer to the same console. You can therefore assume (with a CON: like handler) that all packets that arrive at a particular HAN: process are meant for that process' console. If you, in fact, should receive a new ACTION_FINDwhatever packet with any other name than *, there is some bug somewhere. I think you can ignore the lock that you are given. Since you don't make it yourself, it comes from somewhere (I think I should know from where, but at this moment I don't remember) it is of no practical purpose. Locks are normally only used on filesystem-type handlers, where "being relative to" has some meaning. | - Greg -- Olaf 'Rhialto' Seibert rhialto@cs.kun.nl How can you be so stupid if you're identical to me? -Robert Silverberg