X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f Date: 17 Dec 2003 08:20:46 +0200 Message-Id: From: Eli Zaretskii To: djgpp AT delorie DOT com In-reply-to: (message from Rob Kramer on Tue, 16 Dec 2003 08:24:04 GMT) Subject: Re: statfs() doc patch. References: Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: Rob Kramer > Newsgroups: comp.os.msdos.djgpp > Date: Tue, 16 Dec 2003 08:24:04 GMT > > 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: Thanks for looking into this and for finding a solution. However, I don't see how what you found is explained by the cited fragment from RBIL: it does not say, as far as I could see, that "C:" will lead to a failure while "C:\" will succeed. So it sounds like you found some bug, either in DJGPP or in Windows, but that bug is not documented in RBIL. Am I missing something?