From: Martin Str|mberg Message-Id: <200012281748.SAA05724@father.ludd.luth.se> Subject: Re: Fw: Patch for statfs.c In-Reply-To: from Norberto Alfredo Bensa at "Dec 27, 2000 10:27:27 pm" To: nbensa AT hotmail DOT com (Norberto Alfredo Bensa) Date: Thu, 28 Dec 2000 18:48:10 +0100 (MET) Cc: djgpp-workers AT delorie DOT com (DJGPP-WORKERS) 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 Please Cc: djgpp-workers AT delorie DOT com as I welcome those people's feedback too. According to Norberto Alfredo Bensa: > > From: "Martin Str|mberg" > > > > According to Laurynas Biveinis: > > > + #include > > > > Err. malloc.h? Why do yo need that one? > > curdrive = getcwd (NULL, 256); > . > . > if (curdrive != path) > free (curdrive) /* <-- because of this */ > > > > > > ! long free = 0; > > > long bsize = 0; > > > > > > ! long freec = 0; > > > > Why are you needlessly renaming variables? > > see above... > > > > > > What's the deal with this curdrive? What does it fix? > > > > It is needed by Int 21h / AX=7303... it expects a pathname, not a > drive number. I can't use 'path' because it could be an empty string > and 217303 would fail... > > excerpt from Ralf Brown's PC Interrupt List > > INT 21 - Windows95 - FAT32 - GET EXTENDED FREE SPACE ON DRIVE > AX = 7303h > DS:DX -> ASCIZ string for drive ("C:\" or "\\SERVER\Share") > ES:DI -> buffer for extended free space structure (see #1442) > CX = length of buffer for extended free space > Return: CF clear if successful > ES:DI buffer filled > CF set on error > AX = error code > SeeAlso: AX=7302h,AX=7304h,AX=7305h,AH=36h Hmm. Perhaps calling _put_path(".") if input path is "" would fix that? Without any mallocing. Or perhaps _put_path("") already does the rigth thing? The already present code indicate it does... > Sorry <:-)... > the patch was made in a hurry and only for my personal use! I'm looking forward to a cleaned-up one from you! > > Either I'm misreading something (these non--u patches are hard on > me), > > by 'non--u patches' I guess you mean 'diff -u 3....' would be better, > but djgpp faq section 22.3 says to send patches with 'diff -c...', and > that's what I did... Yes. I'm not critizing you. Only the instructions (the message was sent to djgpp-workers too). By the way you seem to have misread that the patch should go to djgpp-workers not dj... > > but didn't the rescaling disappear? Why? As you had a large drive > your > > program wouldn't even enter this piece of code (so why did you chopp > > Ohh yes, rescaling did disappear. With rescaling, statfs was reporting > the wrong number of free clusters (here at least). And YES, it does > enter that piece of code (IIRC on the 1.3GB free mentioned below). That's how DJGPP always has worked on drives less than ~2GiB. For me it's not obvious the chkdsk values are more correct than DJGPP's. If nobody objects we could discard that backwards compatibility. > > it). Or did it (so what were the values of free and blocks in "if( > > free < blocks )")? > > I can't remember them, but the whole thing about this patch was: > > The original code: > 1. did fail (on Windows) on a 5.5GB free drive... (16 GB total space) > 2. did fail (on Windows) on a 1.3GB free drive... (8 GB total space) > 3. did fail (on DOS) on a 1.3GB free drive (2 or 3 cluster less than > that was reported by chkdsk) Yeah, for drives with less than 2GiB free that's how it works. But I got the impression your patch corrected large free drive space reporting. Please say what your patch does. Sorry if I misunderstood you. > I've said in a previous mail that everything on this patch was done > taking chkdsk as a reference (no, I haven't dissasembled it) You did? > However, it did fail on a mapped network drive... > > NOTE: by 'fail' I mean 'it did not report the actual number of > clusters' Please say what you expected and what you got. (I suspect the reporting for network drives is limited to ~2GiB, right? That's what I'm seeing. If you can figure out how to get right values, please let us know!) > Also, please note that I'm not a Windows/DOS low-level-programming > guru. I'm just guessing!! It works ok right here, all I want is other > people to test this... Me too. But not only guessing. You found some documentation I missed or has been added since I coded this. Thanks! Right, MartinS