Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!oliveb!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga
Subject: Re: Device List and monitoring devices.
Message-ID: <43039@sun.uucp>
Date: 24 Feb 88 18:48:09 GMT
References: <1475@sugar.UUCP>
Sender: news@sun.uucp
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 61
Keywords: Details, details. AmigaDOS and crystal balls.

In article <1475@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
>Well, I need some info. The AmigaDOS manual is not exactly clear as crystal.

>If you have two file names and want to determine if they refer to the
>same device, how do you do it? DeviceProc?

With the same physical device? Well As far as I know the only way to 
really do it is to compare the Locks of the two files. Note that locks
are supposed to be opaque things but I believe they should be comparable
much like pointers. If the files are the same physical file the locks
should match up.

>If you call DeviceProc and don't do anything with the Lock returned in
>IoErr(), what happens to it? Does it leave a loose lock? Is it the ParentDir
>lock, or a root lock, or what?

Good question, Andy? Usually, when you 'get a lock' from one of the system
routines you are expected to UnLock it, (CurrentDir, ParentDir, etc). One
way to check is to *not* unlock it and see if after running your program
you are now have 24 fewer bytes of memory.

>When you come across a DevList entry with Type equal to dt_volume, how
>do you map it to a physical volume ID? Go through the DevList looking
>for dt_device entries with the same Handler process?

I knew this one once but can't remember, must be old age :-). You can
play around with watching the handler field. (This is where having metascope
sit around watching the device list is very instructive.)

>How does Workbench guarantee that it opens the same volume when you have
>two volumes of the same name? Keep a Lock on the volume? Must be more
>than that because closing the last lock on a volume releases it, so
>Workbench can't keep ahold of any for volumes with no open windows.

In the Volume node is a time stamp, this must be unique for each volume
name. 

>My theory: it keeps the timestamp, then when you try to open the disk
>it goes through the DevList looking for a device with the same stamp
>and name... then it DupLocks the Lock. If the volume's not mounted it
>does a Lock on it and then checks the timestamp again... and so on.

Well Workbench gets a lock on the Disk.info file and the root directory
of a volume when it is inserted. The Lock has a pointer to the volume
node and as far as the workbench is concerned it can just use locks
to talk to the disk. (CurrentDir(DiskLock); ReadAllInfoFiles(); Display();)
When you put a disk in the drive and DOS makes a Volume node for it, it
has to note the timestamp to keep from getting confused with another
volume of the same name. 

>It could also keep its set of locks and UnLock them after getting a DiskChange
>message, and relock them after it's rescanned the DevList...

I believe it Checks the list of locks on all Volumes on the workbench when
it gets a disk change, if there are more than it's locks it leaves it up
on the WB, if it is the only one left holding the locks it unlocks them
and the DOS deallocates the Volume node. 


--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.