peter@sugar.UUCP (Peter da Silva) (02/22/88)
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? 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? 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? 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. 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. 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... Or does it have a backdoor???? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
cmcmanis%pepper@Sun.COM (Chuck McManis) (02/25/88)
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.
andy@cbmvax.UUCP (Andy Finkel) (02/26/88)
In article <43039@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <1475@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >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. Caution: Locks are privately allocated structures. Don't go around copying them, or allocating them ,or.... use DupLock() for that. Locks for different handlers and filesystems may be of different sizes... So, with the caution out of the way, you can compare the fields you know about...DiskBlock, ProcessID, and VolNode. > >>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? DeviceProc returns a pointer to a lock, rather than an actual lock itself. Nothing for you to UnLock. >>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? yes. That works nicely. -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Never test for an error condition you don't know how to handle." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
peter@nuchat.UUCP (Peter da Silva) (02/28/88)
In article <43039@sun.uucp>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes: > 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. That tells me that the files are the same physical file. What I want to do is check whether "sys:include" and (say) "VD0:include/workbench" are on the same physical device. I need some good, reliable, way of keeping myself from recursively copying a directory into itself in the face of assigned names when someone picks up the former and drops it in the latter. Right now I don't use assigned names and do string comparisons on the prefixes, but I'd like to be able to let people open directories by 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. I thought it'd be something like this. Let me try something... Yep, that's what it does all right. Just popped a disk while the cloud was up and it didn't clear the locks. So, I can't use the same idea in Browser because I'll confuse WorkBench. I guess I'll have to do the hard work of playing with the timestamps myself... Damn. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.