Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga
Subject: Re: ARRGH! Disk Killer in 1.2
Message-ID: <36349@sun.uucp>
Date: 13 Dec 87 22:22:40 GMT
References: <1539@stb.UUCP> <35591@sun.uucp> <10006@stb.UUCP>
Sender: news@sun.uucp
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 24

In article <10006@stb.UUCP> michael@stb.UUCP (Michael) writes:
>I'm not doing a diskcopy. HEX is not using INHIBIT--everything it looks
>at after checking for a key disk (a least it checks both drives) is dos
>files accessed through dos.

Is HEX using the track disk commands directly? If it was pure DOS calls
what would be the advantage to using HEX over "copy df0: to df1: all" ?
If it is using Trackdisk, then it *should* send an inhibit because it 
is possible for the disk to be in an undefined state when some other
task goes to talk to it. Finally, if HEX uses the TD_ form of the commands
rather than the ETD_ form of the trackdisk commands then they won't 
check for diskchange and the following behaviour will result.

>Once again: A read/write error occurs, I tried switching disks, had
>to manually press retry, and then the hex root track writes over my
>utilities root track.

So do you know who the author of HEX is? Can we contact them via the net?
You could also use MonPort on the trackdisk.device message port to see
what commands were being given.

--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.