From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id: <200101082112.WAA00328@father.ludd.luth.se>
Subject: Re: Fw: Patch for statfs.c
In-Reply-To: <Pine.SUN.3.91.1010108090225.4690G-100000@is> from Eli Zaretskii at "Jan 8, 2001 09:05:38 am"
To: djgpp-workers AT delorie DOT com
Date: Mon, 8 Jan 2001 22:12:18 +0100 (MET)
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

According to Eli Zaretskii:
> > Yes, but if the AX7303 values are correct (when re-scaled to 2048-byte 
> > block size), shouldn't those be what we use?
> 
> We don't have any way of telling if 217303 is correct or not.

I've been mulling this over. I think we just have to accept that INT21
AX=7303 is correct with regard to _total_ _blocks_ and _free_
_blocks. I know that the fact it's lying about bsize isn't encouraging
but the size it's reporting is correct in the sense it's what WINDOZE
reports, right?

Soooo, suppose if we take the (non-block) sizes from INT21 AX=7303 and
the block size from INT2f AX=1510 and then scales the other values
accordingly so in sum it's right (in accordance with WINDOZE).

Comments?


Right,

						MartinS