Re: "DOS" server question

["D.Jeske" <jeske@igcom.net> writes:]

>However, I have a question. Why are there ASSERT_DEBUG statements in the
>dos server? I understand that they can be indespensable in debugging
>situations, however, I would think that it would be unacceptable under
>almost any circumstances to have a filesystem driver dump because of an
>unexpected value unless it was impossible to continue without it (i.e. no
>superblock or something). Especially on a filesystem such as MSDOS FAT
>which can almost never be considered to be in a truly "clean" state.

In general, when I write code which handles end-user data, I tend to write
the code so that everything grinds to a halt if an unexpected value pops up.
My reasoning is that if my code doesn't know what to do with the value, it
doesn't know how to continue. If it just forges ahead anyway, you are
exposing the user to the very real possibility that they will have a
massively corrupt filesystem, rather than a filesystem with a single glitch
associated with a single file.

During my life as a UNIX kernel weenie, I had to trudge through massively
corrupt filesystems time and again on behalf of anxious customers. I'll
take my downtime up front, any day. If you want to continue on in the face
of system inconsistencies, you need a fault tolerant filesystem. You don't
write one of these by accident, and there's no such thing as "sort of" or
"mostly" fault tolerant. IMHO.

I also don't know what you mean by FAT filesystems never being truly
"clean". I routinely will switch back to DOS and run scandisk after a large
amount of work under VSTa. Excepting the occasional DOS server bug (:->),
the filesystems are clean from top to bottom.

                                                        Andy
Received on Sun Jul 2 07:35:06 1995