X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
From:	Rob Kramer <robk AT starhub DOT net DOT sg>
Subject:	statfs() doc patch.
Newsgroups:	comp.os.msdos.djgpp
Lines:	47
User-Agent:	KNode/0.7.2
MIME-Version:	1.0
Message-ID:	<EizDb.3309281$Of.514843@news.easynews.com>
X-Complaints-To:	abuse AT easynews DOT com
Organization:	EasyNews, UseNet made Easy!
X-Complaints-Info:	Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date:	Tue, 16 Dec 2003 08:24:04 GMT
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Hi,

I recently spent some time figuring out why my statfs calls were
intermittently misreporting the number of free blocks. I'm using latest CVS
on a Win98 DOS-mode OS with a 20GB FAT16 drive split in many 2GB partitions
(ugh).

With some tracing I found out it was because I didn't specify the drive
letter fully ("c:" instead of "c:\"), causing the call to return -1 for
blocks free, or sometimes the correct value. RBIL explains this:

INT 21 - Windows95 - FAT32 - GET EXTENDED FREE SPACE ON DRIVE
        AX = 7303h

[chop]

    under DOS 7.x (i.e. "MSDOS Mode" under Windows95), the ASCIZ string
    pointed at by DS:DX *must* include the drive letter, or this function
    will return CF set/AX=0015h (invalid drive).  In a DOS box, omitting
    the drive letter (DS:DX -> "\") results in the free space for the
    current default drive, as expected

On FAT32 the problem doesn't occur, either because 0x7303 works, or because
0x7302 is used. 

Perhaps a note in the documentation would be a good idea:


diff -u -3 -p -r1.8 statfs.txh
--- statfs.txh  7 Feb 2003 18:13:52 -0000       1.8
+++ statfs.txh  16 Dec 2003 08:06:54 -0000
@@ -33,6 +33,10 @@ struct statfs
 Note that if INT 21h is hooked by a TSR, the total size is limited
 to approximately 2GB (@pxref{statvfs}).

+On FAT16 filesystems running Windows 95/98 in DOS mode, @var{filename}
+must contain a complete drive letter specification (e.g. "c:\"), or
+@code{statfs} will return incorrect values.
+
 Note that there is a POSIX-compliant function @code{statvfs}
 (@pxref{statvfs}), which returns similar information.


Cheers,

    Rob

- Raw text -