Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!uakari.primate.wisc.edu!bin
From: bin@primate.wisc.edu (Brain in Neutral)
Newsgroups: comp.sys.mac.system
Subject: Re: 6.0.7 bugs (eek eek!)
Message-ID: <3412@uakari.primate.wisc.edu>
Date: 9 Nov 90 18:16:19 GMT
References: <4642@husc6.harvard.edu>
Sender: bin@primate.wisc.edu
Reply-To: bin@primate.wisc.edu
Lines: 29

From article <4642@husc6.harvard.edu>, by kenh@hscfsas1.harvard.edu (Ken Hancock):
> In article <1T$^K8|@ads.com> jtn@ADS.COM (John T. Nelson) writes:
>>Well after using 6.0.7 for about an hour I see that I've already run into some problems/bugs.  Here's what I've found:
>>
>>1) Copy File is broken.  Put a floppy in the drive and try copying a
>>file from your hard disk to the floppy.  Make sure that the file you
>>are copying is LARGER than the capacity of the target floppy.
>>Dragging the file to the floppy starts the copy and the system
>>complains that the disk is full.  So far so good.  Click "Cancel."
>>The copy is terminated but the files(s) on the floppy are removed!!!
> 
> "Cancel" means "go back to the way it was before I started this
> operation."  File copy SHOULD remove the files.

Not always.  Suppose "x" exists both on the hard disk and the floppy.
Now "cancel" should not delete the original "x" on the floppy.  If it
does, the floppy is not left in the state it was before the copy was
initiated.

The original description of the problem was not clear, but after some
pondering, it seemed to me that the scenario I described in the previous
paragraph might be the one to which jtn was objecting.  If so, his objection
is legitimate, at least in a sense.  One might say that the intent was to
overwrite the files anyway, but still, Cancel is Cancel, and "Apple says..."
--
Paul DuBois
dubois@primate.wisc.edu

                 "Was all of this because I wore a big man's hat?"