gauthier@ntmtv.UUCP (Jay Gauthier) (08/16/90)
Hi, another simple question that I can't find an answer to in IM. How can you tell if a vRefNum refers to a floppy disk drive? Also, how can you tell if it is an AppleShare volume? The general question is "How can I tell if an 'Eject' is a valid option?" Thanks in advance, -- Jay Gauthier BNR, Mountain View CA (415) 940-2101 uucp: ntmtv!gauthier@ames.arpa
marc@Apple.COM (Mark Dawson) (08/16/90)
More experienced people will probably give better answers, but here's my try: In article <1517@ntmtv.UUCP> gauthier@ntmtv.UUCP (Jay Gauthier) writes: >Hi, another simple question that I can't find an answer to in IM. >How can you tell if a vRefNum refers to a floppy disk drive? You can't. You can make educated guesses. If the drive # is 1 or 2 it GENERALLY is a floppy drive, but a 4 or 9 could be too (especially if its a Daynaor Rapport external floppy drive). You can check what driver is running the drive ('.Sony' would tell you that the Sony floppy driver is running, though Rapport also uses this name to fool other callers into thinking its a Sony driver). >Also, how can you tell if it is an AppleShare volume? You again could see if the AppleShare driver owns the drive. There's probably other ways too... >The general >question is "How can I tell if an 'Eject' is a valid option?" > I don't know. I know you CAN eject AppleShare volumes; it justs removes their access from you (off the desktop). Mark -- --------------------------------- Mark Dawson Service Diagnostic Engineering AppleLink: Dawson.M Apple says what it says; I say what I say. We're different ---------------------------------
blob@Apple.COM (Brian Bechtel) (08/16/90)
gauthier@ntmtv.UUCP (Jay Gauthier) writes: >Hi, another simple question that I can't find an answer to in IM. >How can you tell if a vRefNum refers to a floppy disk drive? >Also, how can you tell if it is an AppleShare volume? The general >question is "How can I tell if an 'Eject' is a valid option?" The answer, from the Q&A Stack available on apple.com, is: What you probably want to know is if a device in the drive queue is removable or not. To do this, examine the four bytes of flags preceeding the drive queue entry for this device. See Inside Mac IV-181 & 182 for details. C source is: /* we assume that you get the drive number from some appropriate place, such as doing a PBHGetVInfo for the volume */ Boolean IsEjectable(driveNumber) short driveNumber { DrvQElPtr d; QHdrPtr queueHeader; Ptr p; queueHeader = GetDrvQHdr(); d = (DrvQElPtr)queueHeader->qHead; while (d != nil) /* find the appropriate drive # */ { if (d->dQDrive == driveNumber) /* is this the drive we want? */ { p = (Ptr)d; p -= 3; /* to get to the byte with eject info */ if (*p & 8) /* handles both 0x08 and 0x48 cases */ return false; /* non ejectable disk in drive */ else return true; } d = (DrvQElPtr)d->qLink; } return false; /* you specified an invalid drive number */ } Now if you really want to know if a volume is a floppy or not, use PBHGetVInfo, and multiply out the ioVNmAlBlks (remember, it's unsigned!) times ioVAlBlkSiz. Currently valid sizes include 400K, 800K, 720K, 1440K. How will you handle other sizes from the future? Nasty. That's why I think you are really asking to detect removable media. --Brian Bechtel blob@apple.com "My opinion, not Apple's"
stevec@Apple.COM (Steve Christensen) (08/16/90)
In article <1517@ntmtv.UUCP> gauthier@ntmtv.UUCP (Jay Gauthier) writes: >Hi, another simple question that I can't find an answer to in IM. >How can you tell if a vRefNum refers to a floppy disk drive? Call PBHGetVInfo() (note the "H") with the vRefNum. If the ioVDRefNum field is equal to -5 (the floppy disk driver's refNum), then it's a floppy disk. >Also, how can you tell if it is an AppleShare volume? Check the ioVFSID field after doing the PBHGetVInfo() call. HFS (Mac) disks have an ID of zero. Others are non-zero, but I can't remember what ID AppleShare volumes use. >"How can I tell if an 'Eject' is a valid option?" In this case, I think you'll have to walk the drive queue. With the driver's refNum from above, plus the drive number (in the ioVDrvInfo field), walk the drive queue until you find that drive's entry. The 4 bytes BEFORE the queue entry tell you a bit about the state of the disk: -4 writeProtect bit 7=1: write protected, bit 7=0: write enabled -3 diskInPlace $48=unejectable but notify driver of eject anyway 8=unejectable (no notification) 1-2=disk in drive 0=no disk in drive <0=disk was just ejected -2 installed 1=drive installed, 0=no drive installed -1 sides bit 7=1: 2-sided disk, bit 7=0: 1-sided disk For what you want to do, just check to see if the diskInPlace byte is less than 8... steve -- ____________________________________________________________________ Steve Christensen Internet: stevec@goofy.apple.com Apple Computer, Inc. AppleLink: STEVEC 20525 Mariani Ave, MS 81-CS CompuServe: 76174,1712 Cupertino, CA 95014 "You just contradicted me." "No I didn't." ____________________________________________________________________
cy@dbase.A-T.COM (Cy Shuster) (08/17/90)
...and to tell if a volume is a shared volume, use PBHGetVolParms (see IM V pp. 392-393). --Cy-- cy@dbase.a-t.com
phil@anduin.cs.liverpool.ac.uk (Phil Jimmieson) (08/17/90)
In article <1517@ntmtv.UUCP>, gauthier@ntmtv.UUCP (Jay Gauthier) writes: > Hi, another simple question that I can't find an answer to in IM. > How can you tell if a vRefNum refers to a floppy disk drive? > Also, how can you tell if it is an AppleShare volume? The general > question is "How can I tell if an 'Eject' is a valid option?" Hmm, the answer is that you have to access the drive queue entry for the drive that holds the volume that you're looking at. IM IV p181 says "four bytes of flags precede each drive queue entry; they're accessible only from assembly language" Bzzzzt - wrong!! Tech note 36 shows you how: FUNCTION DriveFlags(aDQEPtr: DrvQElPtr):LONGINT; VAR flagsPtr : ^LONGINT; {we'll point at drive queue flags with this} BEGIN {subtract 4 from DrvQElPtr, and get the LONGINT there} flagsPtr:=POINTER(ORD4(aDQEPtr) - 4); DriveFlags:=flagsPtr^; END; so now you test to see if (DriveFlags and $80000)<>0 then you *cannot* eject it. In order to be able to use all of this you have to examine all of the entries in the drive queue. I can send you a piece of pascal that does all this if you want it, but you're sure to get other offers!! Phil Jimmieson, *************************************************** Computer Science Dept., * JANET : PHIL@UK.AC.LIV.CS.AND **new address** * Liverpool University, * ARPA : PHIL%and.cs.liv.ac.uk@cunyvm.cuny.edu * PO Box 147 *************************************************** Liverpool L69 3BX "The Wild West, where men were men, women were women, and (UK) 051-794-3689 Roy Rodgers was *years* ahead of his time..."
lefty@twg.com (David N. Schlesinger) (08/22/90)
In article <9794@goofy.Apple.COM> stevec@Apple.COM (Steve Christensen) writes: > Check the ioVFSID field after doing the PBHGetVInfo() call. HFS (Mac) disks > have an ID of zero. Others are non-zero, but I can't remember what ID > AppleShare volumes use. This is not a reliable test. _Any_ external file system volume (CD-ROMs, NFS "volumes", etc.) will have a non-zero FSID. Additionally, I don't believe that AppleShare can use a fixed non-zero FSID for its own volumes; it has to derive a value for the FSID based on any other non-zero FSIDs in use the first time an AppleShare volume is mounted. |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>| | David N. Schlesinger || "When I have nothing to say, | | The Wollongong Group || my lips are sealed; | | Internet: Lefty@twg.com || say something once, | | DoD #: 0152 || why say it again?" -- David Byrne | |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|
stevec@Apple.COM (Steve Christensen) (08/22/90)
In article <7796@gollum.twg.com> lefty@twg.com (David N. Schlesinger) writes: >In article <9794@goofy.Apple.COM> Steve Christensen writes: >> Check the ioVFSID field after doing the PBHGetVInfo() call. HFS (Mac) disks >> have an ID of zero. Others are non-zero, but I can't remember what ID >> AppleShare volumes use. > >This is not a reliable test. _Any_ external file system volume (CD-ROMs, >NFS "volumes", etc.) will have a non-zero FSID. Additionally, I don't >believe that AppleShare can use a fixed non-zero FSID for its own volumes; >it has to derive a value for the FSID based on any other non-zero FSIDs in >use the first time an AppleShare volume is mounted. Well I didn't mean to simply test if it's non-zero and assume it's an AppleShare volume. I simply pointed out that its file system ID was non-zero and that hopefully someone else would know what to do at that point... steve -- ____________________________________________________________________ Steve Christensen Internet: stevec@goofy.apple.com Apple Computer, Inc. AppleLink: STEVEC 20525 Mariani Ave, MS 81-CS CompuServe: 76174,1712 Cupertino, CA 95014 "You just contradicted me." "No I didn't." ____________________________________________________________________
60d006@wucc.waseda.ac.jp (Kazuaki Ishizaki) (08/28/90)
>Hi, another simple question that I can't find an answer to in IM. >How can you tell if a vRefNum refers to a floppy disk drive? >Also, how can you tell if it is an AppleShare volume? The general >question is "How can I tell if an 'Eject' is a valid option?" I am interesting in reading this topics. Because I want to know "how can you tell if it is an AppleShare volume?", too. But I am disappointed to know a good conclusion. Please tell me "how can you tell if it is an AppleShare volume?" P.S. I tried to use PBHGetVolParms. But if I execute this function when an AppleShare volume is mounted, this program is hang up.... =================================================================== Kazuaki Ishizaki (Graduate school of science and engineering, Waseda University at Tokyo, Japan. electronics engieering postgraduate course) E-Mail: 60d006@wucc.waseda.ac.jp, ishiz@muraok.waseda.ac.jp Other Mail: 74340,13@CompuServe Telephone: ++81 3 209 5198(Labo.) ===================================================================
cy@dbase.A-T.COM (Cy Shuster) (08/31/90)
In article <3900@wucc.waseda.ac.jp> 60d006@wucc.waseda.ac.jp (Kazuaki Ishizaki) writes: >Please tell me "how can you tell if it is an AppleShare volume?" > >P.S. I tried to use PBHGetVolParms. But if I execute this function > when an AppleShare volume is mounted, this program is hang up.... It works, believe me. You need to completely clear out to zero the PB block you're passing, then set the ioVRefNum, set ioBuffer to point to a buffer you've created to hold the return result, and set ioReqCount to the size of the buffer you're passing in: initPB(); /* sets block to all zeros */ pb.hr.ioParam.ioVRefNum = myRefNum; pb.hr.ioParam.ioBuffer = &SEEioBuffer; pb.hr.ioParam.ioReqCount = sizeof(SEEioBuffer); myErr = PBHGetVolParms(&pb.hr, FALSE); /* check for errors */ if (SEEioBuffer.vMAttrib & bHasOpenDeny) /* then it's a shared volume */ See Inside Mac for the formats of SEEioBuffer. Always clear out your PB blocks: before every call! --Cy-- cy@dbase.a-t.com
tim@hoptoad.uucp (Tim Maroney) (09/03/90)
In article <690@dbase.A-T.COM> cy@dbase.UUCP (Cy Shuster) writes: >Always clear out your PB blocks: before every call! No offense, but I think that's terrible advice. All you have to do is set the particular parameters listed as significant in the call. The arrow is only deceptive in the case of ioNamePtr, which is sometimes listed as a left arrow only, even though you need to set it meaningfully on entry. We all know what wonders of efficient performance Ashton-Tate's Mac applications are. If this is what A-T considers good programming practice, that may have something to do with it. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "God must be a Boogie Man." -- Joni Mitchell
60d006@wucc.waseda.ac.jp (Kazuaki Ishizaki) (09/03/90)
In article <690@dbase.A-T.COM> you write: >It works, believe me. You need to completely clear out to zero the >PB block you're passing, then set the ioVRefNum, set ioBuffer to >point to a buffer you've created to hold the return result, and >set ioReqCount to the size of the buffer you're passing in: . . >See Inside Mac for the formats of SEEioBuffer. Always clear out >your PB blocks: before every call! Thank you. I use this routine, and try it. I thought that I took a good result. and I will try it in TOPS. =================================================================== Kazuaki Ishizaki (Graduate school of science and engineering, Waseda University at Tokyo, Japan. electronics engieering postgraduate course) E-Mail: 60d006@wucc.waseda.ac.jp, ishiz@muraok.waseda.ac.jp Other Mail: 74340,13@CompuServe Telephone: ++81 3 209 5198(Labo.) ===================================================================
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (09/03/90)
In article <12229@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <690@dbase.A-T.COM> cy@dbase.UUCP (Cy Shuster) writes: ->Always clear out your PB blocks: before every call! >No offense, but I think that's terrible advice. All you have to do is >set the particular parameters listed as significant in the call. The >arrow is only deceptive in the case of ioNamePtr, which is sometimes >listed as a left arrow only, even though you need to set it >meaningfully on entry. You should also zero the parameters that are significant in the call, even if they are NOT listed in IM-(4-5). Two that come to mind are ioVersNum and ioMisc. Given that not all significant parameters are listed in the documentation, I have taken to using a fast BlockZero routine to zero the parameter block. The overhead of doing that is MUCH less than either the file IO time or the Debug time. Marc Kaufman (kaufman@Neon.stanford.edu)
urlichs@smurf.sub.org (Matthias Urlichs) (09/04/90)
In comp.sys.mac.programmer, article <12229@hoptoad.uucp>, tim@hoptoad.UUCP (Tim Maroney) writes: < In article <690@dbase.A-T.COM> cy@dbase.UUCP (Cy Shuster) writes: < >Always clear out your PB blocks: before every call! < < No offense, but I think that's terrible advice. [...] < We all know what wonders of efficient performance Ashton-Tate's Mac < applications are. If this is what A-T considers good programming < practice, that may have something to do with it. I fail to see why a small assembly-language DBRA loop to clear a parameter block (that's what I'm using, anyway) could affect I/O performance in any significant way. Dispatching the trap and calling the driver takes longer than even a did-it-the-stupid-way-in-Pascal loop. On the other hand, it is far easier to debug I/O stuff when you can see exactly which parameters are going in, which are returned, and which were changed (PBGetCatInfo comes to mind). It also protects one against gratuitious interface-changing done by Apple, stupid interface-changing done by INITs (yes, that happens :-( ), and mysterious crashes provoked by mistakenly- omitted parameters (you mentioned ionamePtr); at least when they're zero, you'll know where to look for mysterious changes, and running with the VBR register set to a clone of the interrupt table (on 68020/030s) protects you against the evil _BlockMove(somewhere,NIL,larger_than_eight). -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)
maa@clinet.fi (Miika Asunta) (09/04/90)
Has anyone got some kind of serial port version of "stdio.c" and "stdio.h" for THINK C 4.x. I don't know exactly, but I think the necessary modifications could also be made to "console.c" and "console.h". With that kind of ANSI.A4 library it would be very easy to port software to BBS program that I am building. Send any information to: -- ************************************************************************* * Miika Asunta * Double Basist * * internet: maa@clinet.fi * Macintosh Programmer * * UUCP: mcsun!santra!clinet!maa * *
cy@dbase.A-T.COM (Cy Shuster) (09/05/90)
In article <12229@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <690@dbase.A-T.COM> cy@dbase.UUCP (Cy Shuster) writes: >>Always clear out your PB blocks: before every call! > >No offense, but I think that's terrible advice. All you have to do is >set the particular parameters listed as significant in the call. The >arrow is only deceptive in the case of ioNamePtr, which is sometimes >listed as a left arrow only, even though you need to set it >meaningfully on entry. The tradeoff is between speed and upward compatibility. It's not an issue of believing the arrow in the documentation, but also suffering through some of the undocumented changes, and subsequently having calls drop through into the MFS case. In my judgement, this is more than likely Mr. Ishizaki's problem. Note also that errors exist in the docs. --Cy-- cy@dbase.a-t.com
tim@efi.com (Tim Maroney) (09/07/90)
In article <690@dbase.A-T.COM> cy@dbase.UUCP (Cy Shuster) writes: >>>Always clear out your PB blocks: before every call! In article <12229@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >>No offense, but I think that's terrible advice. All you have to do is >>set the particular parameters listed as significant in the call. The >>arrow is only deceptive in the case of ioNamePtr, which is sometimes >>listed as a left arrow only, even though you need to set it >>meaningfully on entry. In article <696@dbase.A-T.COM> cy@dbase.UUCP (Cy Shuster) writes: >The tradeoff is between speed and upward compatibility. It's not an >issue of believing the arrow in the documentation, but also suffering >through some of the undocumented changes, and subsequently having >calls drop through into the MFS case. Could you provide some specific examples of these undocumented changes, please?