Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!portal!cup.portal.com!ts
From: ts@cup.portal.com (Tim W Smith)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Puzzle (answer)
Message-ID: <15157@cup.portal.com>
Date: 27 Feb 89 09:31:01 GMT
References: <15029@cup.portal.com>
Organization: The Portal System (TM)
Lines: 36

A few days ago, I posted a couple of Macintosh puzzles.  Here was
one of them:

< Here's a puzzle.  Suppose a Macintosh disk driver had the following
< bug:
< 
< 	The ioActualCount and ioPosition fields of the parameter
< 	block are not updated after IO operations like they are
< 	supposed to be.  Instead, they are left whatever they
< 	were when the _Read or _Write call was made.
< 
< What would happen?  Would most programs only look at the result code
< and ignore these fields, or would most programs break?

( by the way, ioPosition should have been dCtlPosition in the above ).

Here is the ( surprising ) answer: most things work just fine with
this buggy disk driver.  In six months that I ran with this disk
driver before I became aware of the bug and fixed it, only two
programs cared about these two fields.

HD Partition, from Symantec Utilities, had trouble mounting volumes,
and could never mount passworded volumes.

Other Macintoshes could not use TOPS to mount the disk.  They could
mount any folder on the disk, but they could not mount the whole
disk.

The company we wrote this disk driver for has had it in beta testing
for the last several months with several beta testers, and the TOPS
problem was the only one any beta tester ever found.

I guess that most programs don't look at these fields unless ioResult
is non-zero.

						Tim Smith