michael@stb.UUCP (Michael) (11/30/87)
There is a NASTY disk eater bug in 1.2 Situation: copy of Hex in drive 0, utilities disk in drive 1, facc active. Hex reports a read/write error (the reason I use a copy). Retry doesn't work, so I eject both disks and put switch drives. The system does not automatically detect the disk change (not the first time, I didn't worry), so I hit "retry". Immediately, I get a guru. After re-booting, the hex disk gives me a "disk unreadable" error; the utilities disk claims to be "hex", or so its title says. The bug? There is a requestor in 1.2 that says "You MUST replace disk so and so in drive so and so.". It didn't come up. Nor was the i/o simply flushed and lost; it wrote on the wrong disk. Thank god for disk salv. Michael Gersten Copy protection? Just Say "Off Site Backup" (I'm back) -- : Michael Gersten ihnp4!hermix!ucla-an!remsit!stb!michael : sdcrdcf!trwrb!scgvaxd!stb!michael : The above is the result of being educated at a school that discriminates : against roosters.
cmcmanis@pepper.UUCP (12/04/87)
In article <1539@stb.UUCP> michael@stb.UUCP (Michael) writes: >There is a NASTY disk eater bug in 1.2 > >The bug? There is a requestor in 1.2 that says "You MUST replace disk >so and so in drive so and so.". It didn't come up. Nor was the i/o >simply flushed and lost; it wrote on the wrong disk. This isn't a bug its a feature! :-(. If HEX is doing what I think it is doing. When you DiskCopy something, did you notice how the little disk icons both say "BUSY:" underneath them? Well that is the result of sending an ACTION_INHIBIT to the drive. As far as DOS is concerned your drives are empty, because it has been told by the program to ignore any signals (like diskchange) coming from the drive. Then the copy routine uses the ETD_RAWREAD/RAWWRITE commands for speed (since you aren't looking at the bits why encode/decode them no?) And these don't check for a diskchange either, well you get the picture. The program is just moving bits it don't know nuthin from file systems volumes or whatever, it takes from here, and puts them there, you swap the media and it don't care. Now a "copy Vol1: to Vol2: all" command would have worked since the DOS knows which is the source volume and which is the destination volume. But it doesn't format while it copies either. really your only choice is to just wait until the copy program gives up and then try with a different disk. --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.
michael@stb.UUCP (Michael) (12/12/87)
In article <35591@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <1539@stb.UUCP> michael@stb.UUCP (Michael) writes: >>There is a NASTY disk eater bug in 1.2 >> >>The bug? There is a requestor in 1.2 that says "You MUST replace disk >>so and so in drive so and so.". It didn't come up. Nor was the i/o >>simply flushed and lost; it wrote on the wrong disk. >This isn't a bug its a feature! :-(. If HEX is doing what I think it >is doing. When you DiskCopy something, did you notice how the little >disk icons both say "BUSY:" underneath them? Well that is the result >of sending an ACTION_INHIBIT to the drive. As far as DOS is concerned 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. 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. Michael p.s. Like my .signature says, ... -- : Michael Gersten ihnp4!hermix!ucla-an!remsit!stb!michael : sdcrdcf!trwrb!scgvaxd!stb!michael : "Copy Protection? Just say 'Off site backup'. "
cmcmanis%pepper@Sun.COM (Chuck McManis) (12/14/87)
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.
michael@stb.UUCP (Michael) (12/19/87)
Ok, maybe I need to explain this a bit better. HEX is a game. It uses dos to read its files. (High scores, saved games, maps, etc). At one point I got a "Volume HEX: has a read/write error". I ejected it from drive 0, put it in drive 1, put the disk that had been in drive 1 in drive 0, (switched the two disks), hit retry, and found that trackdisk.device had data in its buffer that it flushed out onto the wrong disk. No requestor was put up saying "Please replace HEX: in drive 0" No requestor was put up saying "You MUST replace HEX: in drive 0" Worse, the disk that I lost had the 1.2 file system on it. So instead of losing just the file names, I lost the first block of several files as well. (Put 1.1 file organization in 1.3 please) Michael -- : Michael Gersten ihnp4!hermix!ucla-an!remsit!stb!michael : sdcrdcf!trwrb!scgvaxd!stb!michael : "Copy Protection? Just say 'Off site backup'. "