Rick Schaut on ‘Disk Is Full’ bug

Posted by Pierre Igot in: Macintosh
May 20th, 2004 • 12:08 pm

Microsoft developer Rick Schaut has a very long piece on the process of identifying and fixing a bug in Word, which refers more specifically to the infamous “Disk Is Full” bug that has plagued Word for years and that I have already had the opportunity to discuss extensively on many occasions.

The piece is far too long and convoluted to be of any interest to Word users, however. It’s obviously a piece written by a developer primarily for other developers, which is fine. I am not really in a position to comment on the relative “quality” of the debugging process described by Rick or the code and underlying architecture of Word that he describes. I also appreciate the fact that Rick mentioned my efforts as part of the process of isolating the bug in its various incarnations.

But I just have to highlight the following:

With this in mind, for Mac Word X, we modified the notion of what would be a “simple” piece of text for the sake of deciding whether or not to copy a piece from the previously-saved document’s file over to the scratch file. To view this in a slightly different way, we made the code that copies undo document referents more aggressive. This resolved another test case that the Mac Word testers had developed, again using a slightly different macro that would eventually cause the “Disk is full” error to occur. This fix didn’t actually make it into the shipping release of Mac Office X, but it was included in a subsequent SR (I don’t recall specifically which one).

At this point, we still don’t know that the problem involves the OS’ open file limit. That discovery didn’t happen until this past summer when, through the very persistent efforts of Mac Word’s current lead tester, we were able to use some tools on Mac OS X to figure out exactly what was happening. While we were able to verify this, we still didn’t know the exact location where Word was failing to open a file due to having hit the OS’ open file limit. Again, we still can’t get this to reproduce under the debugger, and there are a couple of places in the save process where it can fail because the OS won’t let Word open the file. So, rather than scatter fixes all over the place, we went with the sure fix: lower Word’s internal open file limit so we hit it before we hit the OS’ open file limit. This allows the code that nukes the undo stack to kick in, and then save the succeeds.

I must say I find it very hard to believe that Microsoft was not aware of the relation between this bug and the OS’s own open file limit. I remember very specifically the time when this “Disk Is Full” first started being a major pain for Mac users, and, from very early on, it became clear to users like me that this bug was indeed related to the Mac OS’s open file limit.

First, there was the fact that the “Disk Is Full” dialog was sometimes replaced by a “Too Many Files Open” dialog. Then there was the fact that Mac utility developer Alsoft came up with a little utility application for monitoring the total number of open files in Mac OS 8 at any time. I remember specifically using this utility to monitor the number of open files and seeing the number creep up with each save in Word.

Then I also remember specifically reading about the fact that the open file limit in Mac OS 8 was little over 350, which was a very low number, considering that many things were considered open files, including each font used by the system.

And then I remember specifically Mac OS 9 coming out and Mac Word users emitting a big sigh of relief because one of the improvements in Mac OS 9 is that they had bumped the open file limit to several thousands. (A reader provides a link in the comments section on Rick Schaut’s blog page to the Apple tech note on this topic.) And I also remember specifically thinking at the time that it was quite nice of Apple to keep an eye on such things and do something in order to accommodate Word and its need for such an inordinate amount of open files (i.e. one and sometimes even two created after each save command).

Unfortunately for Mac Word users, they soon discovered that the fact that Apple had bumped the open file limit to several thousands did not completely eliminate the Disk Is Full/Too Many Files Open bug in Word, clearly indicating that there was also an internal open file limit in Word itself.

All this was back in the late 1990 and early 2000s. And now Rick Schaut is writing that the discovery that the OS’s open file limit was involved in the bug “didn’t happen until this past summer“? Is he serious? I could have told him four years ago that the OS’s open file limit was involved!

Oh dear, oh dear, oh dear. Is it me, or does there seem to be a major communication problem at Microsoft?

As for the bug itself, I can only agree with the comments of another reader of Rick Schaut’s blog, who says:

Hmm… seems to me that it would just be easier (and better allocate resources on the machine) if Word would just do a better job of cleaning itself up every now and then to not have so many open files.

4 Responses to “Rick Schaut on ‘Disk Is Full’ bug”

  1. Henry Neugass says:

    Wow, it’s hard to know where to begin — and I need to be brief, too.

    I _am_ a software professional, I _do_ write code, and I _have_ chased my share of bugs.

    On its own, Mr. Schaut’s story of bug-chasing makes fascinating reading. But I starting thinking about it…

    o An implementation as complex as Word cries out for built-in debugging mechanisms, such as capturing error and warning events internally. Evidently, according to Mr. Schaut, the only debugging available is of the add-on, after-the-fact varieties.

    o It’s hard to believe the only two alternatives for exercising Word is a) letting users try it, or b) some kind of macro text generation scheme. There are ways of simulating user input…

    o Part of the design for unbounded undo’s should necessarily involve accounting for the potentially unbounded resources it would require. Evidently this didn’t happen.

    o At the point at which reports about “disk full” started filtering in, someone ought to have realized, “hmm, maybe we didn’t manage resources very well” and examine just that issue in the code.

    o Many software designers would have stopped at some point early on and said, “no, we can’t go on consuming system resources in an uncoordinated way,” and implemented some kind of system interface manager module to take care of coordination. It is pretty clear this didn’t happen.

    o Mr. Schaut appears to have confirmed the source trees for Mac and PC Word have irrevocably diverged. If so… this is crazy, counter to the massive industry move toward reusing code, and Microsoft’s own major role in that move. Further, it contradicts common sense: if the underlying data is the same, the code to handle the data should be the same. Of course, the O/S and human interfaces would be different, but those are virtually mechanical issues, and _should_ be entirely separate from operating on the “stuff” of documents.

    Much of this probably preceded Mr. Schaut, and/or is outside his control. No way to prove it, but I’m guessing his managers have ironclad rules about speculative fixes or fixing specific bugs unless the pressure to do so is extremely high, _and_ there is some kind of financial payback to be gained. (Word 2004 appears to be largely unchanged from its predecessor, except –we have reason to believe– for bug fixes.) I’m guessing these managers do a very good job at enforcing these rules. True genius!

  2. Josh says:

    Well I suppose the question now is… is this finally fixed in Word 2004?


  3. Pierre Igot says:

    Josh: Mmm, I wouldn’t bet on it!

    Henry: Expect a flurry of posts on bug fixes (or the lack thereof) in Word 2004 once I get a hold of the new version :).

  4. Henry Neugass says:

    Even though I’ve never encountered it myself, I _am_ hoping this bug is fixed.

Leave a Reply

Comments are closed.