SkyWalker@cup.portal.com (05/16/88)
It is really struct FileLock (Manx messed this up until 3.6a) it is in "libraries/dosextens.h". I'm not sure what else you are looking for. (no .signature yet) --scott--
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/16/88)
:>If so, how far can I trust the definition of the lock in the AmigaDOS Technical :>Reference Manual? I know some of the other structures are off-base, but I have :>not been able to find struct Lock in an include file. : :The routines would work for the AmigaDOS FS handler. (I haven't looked at the :FileLock struct recently so the member names may be off). The problem is that :a "Lock" is an opaque structure that only the handler understands. These are Actually, Locks are quite rigid. The workbench guarantees that... that is, a bug in the workbench guarantees it. You see, the workbench does a very bad thing to locks ... it copies them manually. So the size of a lock MUST be EXACTLY sizeof(struct FileLock) or you will crash the workbench. The fields within a struct FileLock are: fl_Link Usually used to link locks together in a lock list (BPTR) fl_Key disk block # (read: unique key identifying an object in this device.. see below) fl_Access exclusive or shared access fl_Task pointer to the handler's message port fl_Volume BPTR to the Device or Volume node So you see, the only two fields that can possibly take on unspecified meanings are fl_Link and fl_Key... fl_Link would not be used by every day user programs, which leaves fl_Key. The device driver has this one remaining field to discern between objects within the device... Intuitively it will contain the 'same' value for duplicate locks on the same object. Realistically the easiest programming approach IS for it to contain the 'same' value, but of course the device driver writer can always make life harder for himself and not follow this reasoning. For the floppy drivers, disk block numbers are placed in fl_Key. For my RAM: disk sample device driver, I stick a pointer to my directory/ fileheader structure. I.E. you can't assume you know what the value in the fl_Key field means, but can probably assume its uniqueness. -Matt
cmcmanis%pepper@Sun.COM (Chuck McManis) (05/16/88)
In article <8805160340.AA23871@cory.Berkeley.EDU> (Matt Dillon) writes: > Actually, Locks are quite rigid. The workbench guarantees that... >that is, a bug in the workbench guarantees it. You see, the workbench does >a very bad thing to locks ... it copies them manually. So the size of a >lock MUST be EXACTLY sizeof(struct FileLock) or you will crash the workbench. But the workbench is getting moved from ROM->Disk in 1.4 and word at the Developers Conference was that there were 'significant' improvements in the works for workbench. So this is probably one of them. I think the key thing to consider is that the 'architecture' of locks and try not to build in any dependencies one their internal structure. Thus when they change your program won't crash. Note that the only legal way to copy a lock is with the DupLock() call. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
peter@sugar.UUCP (Peter da Silva) (05/17/88)
OK, I ran into Rob Peck on CI$, and got the poop on the Lock being called FileLock in the includes. Now, I have another problem. I really really want to be able to rename a file based on a WBArg structure (directory lock and file name) for each file. I've done versions for each DOS call except Rename by wrapping it into a CurrentDir structure, but I can't think of any efficient way to do it for Rename. I know I can use ParentDir repeatedly to step up the list a bunch and get a real filename for one or the other of the args, but I would expect that to cause mundo disk accesses. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These may be the official opinions of Hackercorp.
peter@sugar.UUCP (Peter da Silva) (05/17/88)
WARNING! UGLY GROSS HACK AHEAD! What does the IDCMP message WBENCHMESSAGE do? Would it be possible to get Workbench to send you messages when it moves files into your windows by setting this in your IDCMP? What would these messages look like? Interesting possibilities. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These may be the official opinions of Hackercorp.
doug-merritt@cup.portal.com (05/17/88)
Peter, your code looks pretty reasonable. Certainly the volume pointers
that you are comparing should point to the same thing, unless someone
write a bogus "assign" sort of program to muck with them. If you
compare the strings pointed to in the dl_Name field of the two volumes,
that should cover even the (unlikely?) case where there are two copies
of the same structure. I doubt that's necessary, but it *would* make
it guaranteed to work.
Hmmm...actually, if you really want to make sure, the absolute postive
way is to take the volume pointer, get the dn_Task field, and then
search for a device with the same dn_Task field. That would absolutely,
positively, no exceptions, be guaranteed to work.
But your pointer comparison might be good enough.
I'm not sure about the second part with the data block, but I'll be
interested to hear whether that works. Hmmm...maybe I should try
it out...
Doug
---
Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt
or ucbvax!eris!doug (doug@eris.berkeley.edu)
or ucbvax!unisoft!certes!dougdoug-merritt@cup.portal.com (05/17/88)
Peter, I forgot to answer your question. You can find the definition of struct FileLock * in libraries/dosextens.h; the definition seems to be fairly reliable (it's worked for me, anyway). Doug
andy@cbmvax.UUCP (Andy Finkel) (05/18/88)
In article <8805160340.AA23871@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >:a "Lock" is an opaque structure that only the handler understands. These are > > Actually, Locks are quite rigid. The workbench guarantees that... >that is, a bug in the workbench guarantees it. You see, the workbench does >a very bad thing to locks ... it copies them manually. So the size of a Actually, only the first 6 fields are public. The lock can be longer. (ram-handler and ffs have extended locks) Workbench doesn't copy locks by hand...it copies (most of) the FileInfoBlock by hand. (Its the most of that gives us problems) Never copy locks by hand. Always use DupLock(). andy -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "C combines the power of assembly language with the flexibility of assembly language." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
peter@sugar.UUCP (Peter da Silva) (05/18/88)
In article <2114@amiga.UUCP>, jimm@amiga.UUCP (Jim Mackraz) writes: > In article <2004@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > )What does the IDCMP message WBENCHMESSAGE do? > It implements the protocol behind CloseWorkBench() and OpenWorkBench(). You mean if I figured out WBENCHMESSAGE I could have browser open and still let Deluxe Paint CloseWorkBench() and OpenWorkBench() on me? > It is system private, subject to change, don't even think about it. I really wish you guys would strip stuff you didn't want people to know about out of the include files, or at least put them inside a #ifdef SYSTEM_PRIVATE. This leading people into temptation is positively biblical. What'll you do if I think about it? Sic the thought police onto me? Afflict me with boils? Fry me in a wok? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These may be the official opinions of Hackercorp.
peter@sugar.UUCP (Peter da Silva) (05/18/88)
In article ... dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > Relatively simple. If you will refer to the DOS packet > ACTION_RENAMEOBJECT, it takes four arguments: OK. Next time I RTFM. > Arg1 = FromLock (src dir) > Arg2 = FromName > Arg3 = ToLock (dst dir) > Arg4 = ToName > All you have to do is construct and send the packet to the proper > handler yourself! Remember, BPTR's and BSTR's. You also *must* ensure > the two locks are on the same device node... a simple field check. And you have so thoughtfully provided the code to send packets to DOS, so I can do the right thing. I presume I can send the packet to: ((struct FileLock *)(lock<<2))->fl_Task. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These may be the official opinions of Hackercorp.
page@swan.ulowell.edu (Bob Page) (05/18/88)
Speaking of rename packets - if you have two files in DF0: ... say they are named f1 and f2. If you say RENAME f1 f2/f3 it works. Well, it kinda works. Well, it doesn't work, DOS gets lost and the file system throws up. As in flashing red box at the top of your display. Haven't tried it with FFS; I like the data on my hard disk, thanks. I heard someplace the new ram-handler has a fix for this. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page
papa@pollux.usc.edu.UUCP (05/19/88)
In article <2014@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >In article <2114@amiga.UUCP>, jimm@amiga.UUCP (Jim Mackraz) writes: >> In article <2004@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >> )What does the IDCMP message WBENCHMESSAGE do? > >> It is system private, subject to change, don't even think about it. > >I really wish you guys would strip stuff you didn't want people to know >about out of the include files, or at least put them inside a #ifdef >SYSTEM_PRIVATE. This leading people into temptation is positively biblical. > >What'll you do if I think about it? Sic the thought police onto me? Afflict >me with boils? Fry me in a wok? He'll do the same that is going to happen to IntuitionBase MouseX MouseY (used by various programs that let you move the mouse to more than 640x400). In 1.4 those variables won't even be looked at by ANY part of the system software, so setting them to any value or retrieving the value will be completely bogus. It is like "now you see it (1.2), now you don't (1.4"" :-) -- Marc Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
peter@sugar.UUCP (Peter da Silva) (05/21/88)
In article <9187@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: > In article <2014@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >What'll you do if I think about it? Sic the thought police onto me? Afflict > >me with boils? Fry me in a wok? > He'll do the same that is going to happen to IntuitionBase MouseX MouseY > (used by various programs that let you move the mouse to more than 640x400). Like Workbench (sitting here with a 704 pixel wide workbench). I know, that's different. Now then. I just got Davide Cervone's excellent screen hack "vscreen". I'm sure it will no longer work under 1.4. Could you guys at least consider off- screen windows (as discussed on the net several times) so I won't feel too bad when it breaks? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These may be the official opinions of Hackercorp.