geoff@eagle_snax.UUCP ( R.H. coast near the top) (10/10/88)
Continuing the saga of DOS 4.00,,,
From groping around in DOS 4.00 with PCWATCH (an invaluable tool),
it seems that there's a new (undocumented) feature which allows
you to force an int24 critical error to be raised on otherwise
nonfatal errors (e.g. out of disk space). This is set as follows:
mov bx, <handle>
mov ax, 4400h
int 21h
mov dh, 01h
mov ax, 4401h
int 21h
(Note that the book says that the low order bits of DH are supposed
to be 0 for a 4401H ioctl.)
Anyway, I just completed some further analysis of this feature. If you
open a file and start writing to it, AX normally returns the
count of bytes written (i.e. AX = CX); when the disk fills up, the
call does not fail (i.e. CARRY is clear), but AX is returned
with a value less than CX (typically 0).
If the "force-critical-errors" mode is turned on, exhausting the disk space
causes an int24 to occur with:
AX = 0F00
DI = 000C
Interpreted, this means (from AX), "disk error", "writing", "data area",
"FAIL is allowed", "RETRY is not allowed", "IGNORE is not allowed", and
(from DI), "General failure". Interestingly DOS is able from this
to intuit that the correct error message to display is
Insufficient disk space writing drive A
No surprise about the last three words, but is the ONLY "general writing
data" error "Insufficient disk space"?
Furthermore, if the caller sets both "force-critical-errors" (via ioctl) and
"inhibit-critical-errors" (via OPEN 6C), the "inhibit" wins out, and
the system call fails immediately with AX = 0005H (access denied);
the caller cannot find out how much data was written.
Note that this only applies to writing! If you open an existing file
(exist=Open, non-exist=Fail, inhibit-critical-errors=Yes,
force-critical-errors=Yes), and read from it, you'll get the
"Out of input reading drive A" error at EOF. The int24 arguments
are AX=0E00, DI=000C (i.e. "disk error", "reading", "data area",
"FAIL is allowed", "RETRY is not allowed", "IGNORE is not allowed", and
"General failure"). In this case, the "inhibit-critical-errors" mode
is apparently ignored....
This is starting to look terribly ad hoc...
--
Geoff Arnold, Sun Microsystems Inc.+------------------------------------------+
PC Distrib. Sys. (home of PC-NFS) |If you do nothing, you will automatically |
UUCP:{hplabs,decwrl...}!sun!garnold|receive our Disclaimer of the Month choice|
ARPA:garnold@sun.com +------------------------------------------+