Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!think.com!mintaka!goldilocks.lcs.mit.edu!dcw
From: dcw@goldilocks.lcs.mit.edu (David C. Whitney)
Newsgroups: comp.sys.apple2
Subject: Another GS/OS quirk
Message-ID: <1990Sep7.120708.5324@mintaka.lcs.mit.edu>
Date: 7 Sep 90 12:07:08 GMT
Sender: daemon@mintaka.lcs.mit.edu (Lucifer Maleficius)
Reply-To: dcw@goldilocks.lcs.mit.edu (David C. Whitney)
Organization: MIT Spoken Language Systems Group
Lines: 27


I wouldn't exactly call this a bug, but in can get a bit annoying...

Ever do a single-drive disk to disk copy? I mean, say you have to back
up SYSTEM.DISK, and you only have one drive. Pop in the source disk
and eject it by hitting the button on the drive. The icon greys (if
there are windows open, all those icons grey too). Now pop in the
destination disk and drag the grey to the solid. The copy progresses.
No problems here.

The deal is, GS/OS remembers all the disk inserts/ejects that happen
during the copy. When the copy is all done, it "plays out" all those
ejects and inserts. Any displayed icons grey and solidify repeatedly
- once for each disk switch. This can be amusing the first time, but
it really shouldn't be happening...

Shouldn't the copy routine be absorbing the disk insert/eject events
for those disks being copied? Assuming that a Multifinder-like program
will be available sooner or later, disk insert and eject events should
not all be killed - only those correspoding to the disks being copied.
Well? Huh? So?

--
Dave Whitney			| I wrote Z-Link and BinSCII. Send me bug
Computer Science MIT 1990	| reports. I need a job. Send me an offer.
dcw@goldilocks.lcs.mit.edu	| My opinions, you hear? MINE!
dcw@athena.mit.edu		| Are you sure you know what you're doing?