X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Rob Kramer Subject: statfs() doc patch. Newsgroups: comp.os.msdos.djgpp Lines: 47 User-Agent: KNode/0.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Message-ID: 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