🚀 go-pugleaf

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