Mail Archives: djgpp-workers/2000/12/28/12:48:24
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" <ams AT ludd DOT luth DOT se>
>
>
> > According to Laurynas Biveinis:
> > > + #include <malloc.h>
> >
> > 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
- Raw text -