🚀 go-pugleaf

In article <1415@daimi.UUCP> jnp@jupiter.UUCP (J|rgen N|rgaard) writes:
>In article <8WKQ4ZI1DU-0QO008d@andrew.cmu.edu> jv0l+@andrew.cmu.edu (Justin Chris Vallon) writes:
>>How about this one:

>>        Please insert the disk:
>>        RamDisk

>>Not a chance...

>Isn't it the driver for the ramdisk that is responsible for not
>ejecting it ?

There's a field in the drive queue element which indicates (among
other things) whether the drive holds an ejectable medium.  Generally,
Mac software is pretty casual about observing this flag.  _Eject, for
example, doesn't check it.  Instead, you're supposed to check it
*before* trying to eject a disk.  Fortunately, the standard file
dialogs do check it, so the problem doesn't come up too often.

A well-written ramdisk needs several lines of defense.  (A poorly
written one, like the atrocity that comes with Aztec C, hasn't got any
defenses at all.)  First, it should set the "not ejectable" flag.
Second, it should post a disk inserted event whenever it receives an
eject call.  Third, it should check periodically to see whether it's
mounted (i.e., whether it's volume is on-line in the vcb queue), and
post a disk inserted event if it's not.

Some programs are incredibly stupid about ejecting disks.  Old
versions of Microsoft Multiplan were the worst.  They expected to find
the key disk in the internal floppy drive.  If it wasn't there, they
ejected *the current system disk* (not the floppy) and put up a modal
dialog asking for the key disk.  They didn't care whether the disk
that they "ejected" was a ramdisk, hard disk, or floppy, they just
blew it away.

Ephraim Vishniac					  ephraim@think.com
Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214

     On two occasions I have been asked, "Pray, Mr. Babbage, if you put
     into the machine wrong figures, will the right answers come out?"