Date:	Tue, 17 Mar 1998 18:39:27 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Martin Stromberg <Martin DOT Stromberg AT lu DOT erisoft DOT se>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Where to get the latest sources for djtar
In-Reply-To:	<199803171209.NAA06351@propus.lu.erisoft.se>
Message-ID:	<Pine.SUN.3.91.980317183040.19045H-100000@is>
MIME-Version:	1.0

On Tue, 17 Mar 1998, Martin Stromberg wrote:

> Well I tried looking at the error code in the registers from the 
> __dpmi_int(21,39) call. The only error code I can get is 5. 

Error code 5 is the ubiquitous DOS "Access denied" lossage.  Most of the 
errors which DOS detects get this code.  I guess DOS coders didn't want 
to mess with sophisticated and complex error handling.

> I've also tried calling INT21/59 (Get Extended Error or somthing like
> that) and I always get the same information: (ah, bh, bl, ch) = 
> (5, 3, 3, 2), for all the errors.

2159 is only good for those old DOS functions that don't return the error 
code in AX.  For those which do, it doesn't add much info, which is what 
you see.  The first 3 is again ``access denied'', the second 3 means 
``prompt the user for corrective action'' and 2 means the problem was 
detected in the block device driver (as if we didn't know that already).

I guess checking for disk full is so expensive that DOS itself avoids 
doing it, because there is no such error code in the entire list of codes 
in the Interrupt List.

> If there aren't any then I can't see how else to know that the disk is
> full, except calling statfs.

I think that since this is expensive and since djtar will cope with this 
(after the patch I suggested), we can live with this limitation of 
`mkdir'.  In other words, let the applications which need to handle this 
call `statfs' if they want.

- Raw text -