dplatt@coherent.com (Dave Platt) (07/02/88)
This evening, I noticed some strange symptoms that lead me to believe
that System 6.0 doesn't get along with at least one model of Micah hard
disk. The disk in question is the model AT100 internal hard disk for
the Mac II.
Symptoms:
1) Disk First Aid 1.4 (which comes with the System Software 6.0 update)
refuses to scan the disk; it reports "This is not an HFS disk".
2) Disk First Aid 1.3 (from the System Software 5.0 package) scans the
disk and finds no errors at all.
3) Attempting to erase the AT100 disk while running under System 6.0
results in the appearance of a floppy-disk-style "Do you really want
to erase this disk?" dialog box; the disk's icon is displayed
correctly, but the box is equipped with "one-sided" and "two-sided"
buttons.
4) Actually erasing the disk causes the disk to become unmounted, with
no error message... the icon simply disappears from the Finder
desktop.
5) Attempting to mount the drive by rebooting causes a crash (ID=02)
when the Finder desktop appears.
6) Reformatting the drive doesn't help... System 6.0 insists on trying
to initialize it as if it were a floppy disk, with ID=02 crashes
resulting.
The only way out, as far as I can tell, is to reboot under System 4.2,
reformat the drive, and then reboot and initialize the drive under 4.2.
Once I had done this I was able to restore my backup set (including
System 6.0) and continue without problems.
I've sent a complete description of the problem off to one of Micah's
people via email, and will call them next week.
NOTE: Users of Rodime 100-meg internal drives might encounter similar
problems... I believe that the Micah driver/formatter is based on the
Rodime version. If Disk First Aid 1.4 reports that the disk isn't HFS,
then _don't_ try to erase and restore it under System 6.0!
HYPOTHESIS: Based on these symptoms, and on the symptoms that some users
of CMS drives have been reporting, I'm beginning to suspect that the Mac
is now looking at some fields in the driver information, or in the disk
partition tables, that it had not previously been examining... and that
some vendors' drivers or formatters haven't been filling these fields in
correctly. Just a guess...
--
Dave Platt VOICE: (415) 493-8805
USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303
UUCP: ...!{ames,sun,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com
INTERNET: coherent!dplatt@ames.arpa, ...@sun.com, ...@uunet.uu.nettim@ism780c.isc.com (T.W."Tim" Smith, Knowledgian) (07/03/88)
In article <6218@coherent.com> dplatt@coherent.com (Dave Platt) writes:
< HYPOTHESIS: Based on these symptoms, and on the symptoms that some users
< of CMS drives have been reporting, I'm beginning to suspect that the Mac
< is now looking at some fields in the driver information, or in the disk
< partition tables, that it had not previously been examining... and that
< some vendors' drivers or formatters haven't been filling these fields in
< correctly. Just a guess...
I doubt it. I have a formatter that only supports the old format partition
table. There *aren't* any fields in the old format partition table to be
filled in incorrectly.
Also, there is no need for the file system to know anything about the
partition table anyway. That is just for the driver to use. Initializing
a file system is a file system operation. Everything that the file
system needs to know to initialize a disk should be obtainable from
the drive queue entry.
In other words, if a driver works well enough to boot, and be usable
when a file system is already on the drive, then the Finder should be
able to initialize the disk. I suspect Apple has some sort of bug in
DIZero() for system 6.
--
Tim Smith tim@ism780c.isc.com
"I don't practice what I preach because I'm not the
kind of person I'm preaching to" -- J.R. "Bob" Dobbs