X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: Rob Kramer <robk AT starhub DOT net DOT sg>
Subject: Re: statfs() doc patch.
Newsgroups: comp.os.msdos.djgpp
References: <EizDb.3309281$Of DOT 514843 AT news DOT easynews DOT com> <upteodkxt DOT fsf AT elta DOT co DOT il>
Lines: 101
User-Agent: KNode/0.7.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Message-ID: <EsXDb.3404631$Of.531790@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: Wed, 17 Dec 2003 11:53:08 GMT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii wrote:
>> 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?

Well, perhaps I've been liberal in my interpretation of the RBIL such that
it matches my experimental results. :)  In the bit I snipped from the RBIL
extract:

INT 21 - Windows95 - FAT32 - GET EXTENDED FREE SPACE ON DRIVE
        AX = 7303h
        DS:DX -> ASCIZ string for drive ("C:\" or "\\SERVER\Share")

Together with the cryptical 'in windows DOS box, omitting DS:DX -> "\"
doesn't return invalid drive', I thought that sort of explained it.

If you omit the '\' from 7303, it returns 0x15 indeed. So it's not a DJGPP
bug, but an int21 0x7303 feature.. I think it would be a bit dodgy to
append a backslash inside DJGPP's statfs implementation. Passing "c:\\"
fails as well.

Another funny feature on this platform is that statfs seems to work after
one correct call has been made, using 'c:\' for subsequent badly formed
calls. For example:

[after reboot]

C:\>statfs c:
Results for `c:':

Total blocks: 65505
Available blocks: -1
Block size: 32768

C:\>statfs c:\
Results for `c:\':

Total blocks: 65505
Available blocks: 65483
Block size: 32768

C:\>statfs c:
Results for `c:':

Total blocks: 65505
Available blocks: 65482     <-- actually refers to c:\
Block size: 32768

C:\>statfs blah
Results for `blah':

Total blocks: 65505
Available blocks: 65481     <-- actually refers to c:\
Block size: 32768

C:\>statfs d:\
Results for `d:\':

Total blocks: 65505
Available blocks: 65505     <-- d:\ indeed
Block size: 32768

C:\>statfs blah
Results for `blah':

Total blocks: 65505
Available blocks: 65480     <-- c:\ again!
Block size: 32768


[note: block count decreases because I redirected these results to disk,
example command lines don't show that. This also shows the command works
properly and isn't using a cached 'stuck' value somewhere.]

Cheers,

    Rob