Eliot.Henry@samba.acs.unc.edu (BBS Account) (10/03/90)
I was following the discussion a month ago about determining if a drive is a floppy drive. I need to figure out how to create a list of all hard drives (BOTH SCSI and nonSCSI) Any help, or suggestions or sample code in C or pascal would be greatly appreciated! The file manager is so confusing! Thanks again! Eliot Henry --
gurgle@well.sf.ca.us (Pete Gontier) (10/04/90)
In article <1219@beguine.UUCP> Eliot.Henry@samba.acs.unc.edu writes: > I was following the discussion a month ago about determining if a drive is >a floppy drive. I need to figure out how to create a list of all hard drives >(BOTH SCSI and nonSCSI) Any help, or suggestions or sample code in C or pascal >would be greatly appreciated! The file manager is so confusing! Thanks again! Whew! This is a doozy. What I've done in the past is very complex. Here's a summary: get the vRefNum of the volume you want to ID run the VCB queue looking for that vRefNum get the handle (pointer) to the volume's driver get the name of the driver - it's at an offset into the driver do all sorts of fun string comparisons .SCSI00 Apple SCSI volume .AFPTranslator AppleShare .TOPS TOPS You can write a little program which will allow you to select volumes and list their driver names. The problem is that some of the names are misleading. For example, third-party SCSI and CD-ROM drives don't have driver names that match Apple's. The most confusing part is when you get a result of .SONY. .SONY is supposed to be the driver for floppy drives, and it is, but it's also the driver for the old Apple HD20 (notice lack of SC). So you end up doing size comparisons. Real fun stuff. You can get a tech note from Sitka Corp. (the makers of TOPS) on this topic if you sound like you're serious about TOPS compatibility. I should add that it's now someone's cue to pipe up and bitch about how it's bad practice to run the VCB queue and read strings directly out of drivers and such like. Well, it is. Let's hope the person who ends up writing this also is able to supply a better methodology. -- Pete Gontier, gurgle@well.sf.ca.us Software Imagineer, Kiwi Software, Inc.
russotto@eng.umd.edu (Matthew T. Russotto) (10/05/90)
In article <20945@well.sf.ca.us> gurgle@well.sf.ca.us (Pete Gontier) writes: >In article <1219@beguine.UUCP> Eliot.Henry@samba.acs.unc.edu writes: >> I was following the discussion a month ago about determining if a drive is >>a floppy drive. I need to figure out how to create a list of all hard drives >>(BOTH SCSI and nonSCSI) Any help, or suggestions or sample code in C or pascal >>would be greatly appreciated! The file manager is so confusing! Thanks again! > >Whew! This is a doozy. What I've done in the past is very complex. Here's a >summary: > > get the vRefNum of the volume you want to ID > run the VCB queue looking for that vRefNum > get the handle (pointer) to the volume's driver > get the name of the driver - it's at an offset into the driver > do all sorts of fun string comparisons > .SCSI00 Apple SCSI volume > .AFPTranslator AppleShare > .TOPS TOPS Hmm.. it isn't actually that hard-- why not walk the drive queue looking for nonejectable, writeable drives? (Call drivestatus to see if the drive is writeable-- this will exclude CDs, and hardware-locked hard drives) (you won't get any remote volumes, but you can't find out what they are anyway) -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
gurgle@well.sf.ca.us (Pete Gontier) (10/07/90)
In article <1990Oct4.205555.3700@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes: >In article <20945@well.sf.ca.us> gurgle@well.sf.ca.us (Pete Gontier) writes: >>In article <1219@beguine.UUCP> Eliot.Henry@samba.acs.unc.edu writes: >>> I need to figure out how to create a list of all hard drives >>>(BOTH SCSI and nonSCSI) >> >>Whew! This is a doozy. What I've done in the past is very complex. Here's a >>summary: >> >Hmm.. it isn't actually that hard-- why not walk the drive queue looking >for nonejectable, writeable drives? >(Call drivestatus to see if the drive is writeable-- this will exclude CDs, >and hardware-locked hard drives) Well, the problem with this method is that as soon as you have Syquest volumes lying around, your test fails, because they're ejectable. The sad part is that even my test fails to gather info regarding these drives. It turns out that as we used the method of getting the volume's driver name, it became apparent that third parties found it necessary to name their SCSI drivers something other than ".SCSI00" and third-party CD-ROM makers found it necessary to do something similar. Why this happened, I don't know. Maybe Apple told them not to use the name. I suspect, though, that it was ego. This is a sticky problem; I think Apple's paradigm of device-independence breaks down in some places. Or is enforced too enthusiastically. >(you won't get any remote volumes, but you can't find out what they are >anyway) Sure you can; do it by running the VCB queue and querying driver names as I explained. What I'd really like to see as a response from Apple to all this is a ROM call, perhaps named GetVCBInfo, which would parallel GetFCBInfo. But even that wouldn't help with the naming problems. It would have to be more comprehensive. -- Pete Gontier, gurgle@well.sf.ca.us Software Imagineer, Kiwi Software, Inc.
russotto@eng.umd.edu (Matthew T. Russotto) (10/07/90)
In article <21041@well.sf.ca.us> gurgle@well.sf.ca.us (Pete Gontier) writes: >In article <1990Oct4.205555.3700@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes: >>In article <20945@well.sf.ca.us> gurgle@well.sf.ca.us (Pete Gontier) writes: >>>In article <1219@beguine.UUCP> Eliot.Henry@samba.acs.unc.edu writes: > >>>> I need to figure out how to create a list of all hard drives >>>>(BOTH SCSI and nonSCSI) >>> >>Hmm.. it isn't actually that hard-- why not walk the drive queue looking >>for nonejectable, writeable drives? >>(Call drivestatus to see if the drive is writeable-- this will exclude CDs, >>and hardware-locked hard drives) > >Well, the problem with this method is that as soon as you have Syquest >volumes lying around, your test fails, because they're ejectable. OK. Define 'hard drive'. Is a floppy a hard drive (guess not). A Bernoulli (welll....?) How about a Syquest? Or a Quantum Q250 (Obviously) >The sad part is that even my test fails to gather info regarding these drives. >It turns out that as we used the method of getting the volume's driver name, >it became apparent that third parties found it necessary to name their SCSI >drivers something other than ".SCSI00" and third-party CD-ROM makers found >it necessary to do something similar. Why this happened, I don't know. Maybe >Apple told them not to use the name. I suspect, though, that it was ego. > >This is a sticky problem; I think Apple's paradigm of device-independence >breaks down in some places. Or is enforced too enthusiastically. What exactly is it you need to know? >>(you won't get any remote volumes, but you can't find out what they are >>anyway) > >Sure you can; do it by running the VCB queue and querying driver names >as I explained. But all you can find out is that it IS a remote volume, not whether it is a floppy, hard drive, write only memory, etc... -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
gurgle@well.sf.ca.us (Pete Gontier) (10/08/90)
In article <1990Oct6.194429.24105@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes: >In article <21041@well.sf.ca.us> gurgle@well.sf.ca.us (Pete Gontier) writes: >>Well, the problem with this method is that as soon as you have Syquest >>volumes lying around, your test fails, because they're ejectable. > >OK. Define 'hard drive'. Is a floppy a hard drive (guess not). A Bernoulli >(welll....?) How about a Syquest? Or a Quantum Q250 (Obviously) That's another problem. Another hard call to make. Another reason for Apple to cut us some slack on the almighty device-independence paradigm. Some of us really _do_ need to determine what media is out there. >What exactly is it you need to know? Well, I'll give the specific example in my experience. We decided one day that we needed to re-evaluate which kinds of volumes we were going to support with KiwiFINDER. Network volumes were right out because the design spec didn't include AFP interface. Floppy volumes were out because it was too likely a user would circulate a floppy around, have someone change it, and then be confused when the catalog was no longer up-to-date. Then someone mentioned Syquest drives. You can carry those around from machine to machine, but they're 40M and it's likely people would like to be able to build catalogs on them. And then you have the 20M floppies to confuse the issue even further. And updating a catalog on a WORM drive... ick. Etc. etc. What happens is you have developers trying to make informed decisions to avoid confusing the user unnecesarily, and the developers don't even have legitimate tools with which to gather the information they need. Bunch of blind men fumbling about in the dark. >>>(you won't get any remote volumes, but you can't find out what they are >>>anyway) >> >>Sure you can; do it by running the VCB queue and querying driver names >>as I explained. > >But all you can find out is that it IS a remote volume, not whether it is >a floppy, hard drive, write only memory, etc... Ah, quite correct. I never imagined anyone would care about the medium once a given volume was determined to be some kind of remote network volume. Somebody might want to in order to make performance estimates, I suppose. -- Pete Gontier, gurgle@well.sf.ca.us Software Imagineer, Kiwi Software, Inc.
Eliot.Henry@samba.acs.unc.edu (BBS Account) (10/08/90)
I want to ignore remote drives (the program erases drives and uses low level calls to do it besides even if i could treat the remote drives the same I don't want to erase them) I want to determine what hard drives are connected and their volume names. It seems like such a simple problem. Someone must have done it. This is a reply to the person who said "what exactly do you need to know" I also need to determine if each hard drive is a scsi device so i can treat it differently. So far the best sounding answer i have suggests going through the drive queue looking for drives with driver numbers other than -5 that are unejectable and have a certain minimum size. Eliot Henry --
russotto@eng.umd.edu (Matthew T. Russotto) (10/09/90)
In article <1262@beguine.UUCP> Eliot.Henry@samba.acs.unc.edu (BBS Account) writes: > > I want to ignore remote drives (the program erases drives and uses low level >calls to do it besides even if i could treat the remote drives the same I don't >want to erase them) I want to determine what hard drives are connected and their >volume names. It seems like such a simple problem. Someone must have done it. >This is a reply to the person who said "what exactly do you need to know" >I also need to determine if each hard drive is a scsi device so i can treat >it differently. > >So far the best sounding answer i have suggests going through the drive queue >looking for drives with driver numbers other than -5 that are unejectable and >have a certain minimum size. (don't forget writeable-- you won't get anywhere erasing a CD-ROM) One more thing-- you will first probably want to search the SCSI bus for drives first, and save some descriptive info about any you find. That way you will know what drives are SCSI and what drives are not You really want to erase all hard drives connected to your system? Sounds like a dangerous program to leave lying around!!! (hard to test, too) -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.