‘Disk Is Full’ bug in Word: another Microsoft developer chimes in

Posted by Pierre Igot in: Macintosh
May 20th, 2004 • 11:38 pm

While reviewing Rick Schaut’s blog entry on the “Disk is full” bug in Word yesterday, I couldn’t help but notice that one of the people who had commented on his entry was another Microsoft developer named Larry Osterman. His comment was in response to a comment by Rick Schaut himself about the number of open files per process allowed in Mac OS X. Rick Schaut indicated that it was 256 by default for historical reasons, but could be modified, and he provided a link to the Apple Developer Technote about the issue.

Larry Osterman’s only comment is to say:

Oh my goodness. 256 handles/process? That’s obscenely painful. I’m not surprised this showed up on Mac’s only.

There is plenty that is very, very wrong with this comment. First of all, the plural form of “Mac” is “Macs”, not “Mac’s” — I guess not every Microsoft developer is a good speller. That’s OK…

The main problem is that Larry Osterman didn’t even bother to read what Rick Schaut wrote and to check the technote that Rick referred to. (Of course, the fact that the link to the technote in Rick Schaut’s comment doesn’t work because it’s not formatted properly probably doesn’t help… I guess that blogging system that they use at Microsoft still need quite a bit of fine-tuning.)

If Larry had checked the technote, he would have noticed that it says:

For historical BSD reasons, the OS limits you to only 256 open file descriptors. Files used by DiscRecording can use two descriptors each; one for the data fork and one for the resource fork; so you can hit the limit pretty quickly if you’re not careful.

The good news is that this limit is only a soft limit. You can actually have as many open files as you want. To allow this, you have to explicitly make the following call…

In other words, it’s just a default limit, and there’s no problem with changing it to whatever you need. Instead of reading carefully, Larry lashes out against the Mac platform, with a comment that clearly implies that the Mac architecture is defective to begin with and that it’s no wonder that Mac users are confronted with bugs that would never happen on the Windows side… right?

Well, if Larry Osterman had researched the issue a tiny bit more before commenting, he would also have learned that the “Disk is full” bug does indeed affect Windows versions of Word, because, as Rick Schaut explains, the problem is related to a core aspect of how Word works, both in its Mac and its Windows incarnations. In fact, a quick search for “Disk is full Word” in the Microsoft Knowledge Base turns up all kinds of references to the problem in Windows versions of Word, including Word 95, Word 97, and Word 2000.

The reason I am writing about this is because, once again, it seems pretty clear to me that there is a major attitude problem at Microsoft. Here you have a developer with his own blog who, instead of properly researching issues, finds it appropriate to lash out against the Mac platform when there is absolutely no reason to do so.

These blogs by Microsoft developers provide us with insights not just into how they work at Microsoft, but also into what their attitude is as human beings involved in developing software for the Windows and Mac platforms. And, so far, I have to say that the picture isn’t very pretty.


2 Responses to “‘Disk Is Full’ bug in Word: another Microsoft developer chimes in”

  1. ryan says:

    It seems that many of the commenters didn’t actually read the article! It was long, but the author clearly indicated that the bug was cross-platform. Larry Osterman who commented that he wasnt surprised this showed up on Mac only clearly didn’t read the article.

    Another point is the 256 files/process limit is pretty common in unix-alike systems. This is to prevent a process from taking the machine down if they start doing naughty things. Leaking file handles/sockets is a pretty major sign of a bug in your process. If you know you will need more than 256 handles, it is a simple call to up the limit. Usually the hard limit for handles open/process is 4k or 8k, or more.

    Another thing I’d like to point out is schroden-bugs… those bugs which dissapear every time you try to pin them down. Debuggers and printf lines change the profile of a process and can add enough timing to cause a bug to dissapear. These are more common on real-time and embedded software systems.

  2. Pierre Igot says:

    Ryan: Thanks for the additional information and comments. My single major issue with Microsoft is that there are tons of bugs that should be fairly easy to pin down even without the use of a debugger (which might cause the bugs to disappear, as you said). Far too
    often, I get the impression that Microsoft doesn’t even conduct the most basic type of testing. How could they miss the new bug in Word 2004 that causes the selection to extend to an extra word on the left, for example? I encountered it within 10 minutes of just using the software, for crying out loud.

    As for the Disk Is Full bug, the only reason it is hard for Microsoft to pin it down is the very complexity of their own code. Blaming the user for this (“if you don’t provide us with a reproducible behaviour, we can’t fix it”) is a bit rich.

Leave a Reply

Comments are closed.