X-Originating-IP:	[200.42.4.138]
From:	"Norberto Alfredo Bensa" <nbensa AT hotmail DOT com>
To:	"Martin Str|mberg" <ams AT ludd DOT luth DOT se>
Cc:	<djgpp-workers AT delorie DOT com>
References:	<200012281748 DOT SAA05724 AT father DOT ludd DOT luth DOT se>
Subject:	Re: Fw: Patch for statfs.c
Date:	Fri, 29 Dec 2000 02:11:15 -0300
Organization:	nBens@ Computers
X-Priority:	3
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE:	Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID:	<OE59o3DjFbUcOV1EetV0000214e@hotmail.com>
X-OriginalArrivalTime:	29 Dec 2000 05:13:52.0124 (UTC) FILETIME=[223293C0:01C07156]
Reply-To:	djgpp-workers AT delorie DOT com

From: "Martin Str|mberg" <ams AT ludd DOT luth DOT se>
> Please Cc: djgpp-workers AT delorie DOT com as I welcome those people's
> feedback too.
>

I was about to ask you if I should CC to djgpp-workers... Thanks...


>
> Hmm. Perhaps calling _put_path(".") if input path is "" would fix
> that? Without any mallocing.

I'll try that...

>
> Or perhaps _put_path("") already does the rigth thing? The already
> present code indicate it does...

Hmm... it does with the code on cvs, but the service I'm calling
(217303) fails with an error condition... I'll try the above
solution...

>
> > 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!

I'll modify my patch to get rid of malloc.h and free(), leave all the
variables with their original names, test the new patch on fat32 and
fat16 drives (both huge and not so huge ones), and then re-send the
new patch... I want to make sure I didn't break anything (hmmm, may be
rescaling will disappear, read below).


>
> By the way you seem to have misread that the patch should go to
> djgpp-workers not dj...

<quote from djgpp faq section 22.3>
Patches to DJGPP programs and ports should be sent to the person who
maintains the relevant package.  Patches for the C library, utilities
and other software which comes with the `djdevNNN.zip' distribution
should be sent to DJ Delorie <dj AT delorie DOT com>.  If you don't know who
maintains a particular package or port, post the patches to
comp.os.msdos.djgpp news group, since the maintainer is most probably
reading that group.
</quote>

At first I posted on comp.os.msdos.djgpp as the faq says. Then Eli
Zaretskii tolds me to read the faq section 22.3... never mind, I'll
send every question or patch related to libc directly to djgpp-workers
from now on...

and BTW, I'll send patches as messages as you told me. FAQ says to run
dtou over the patch to make it compatible with unix (that's where
those '=0A=' came from).


> 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.

I've never said chkdsk values were more reliable than those from
DJGPP's, but I got confused and I started to think that statfs was
"buggy"...

>
> If nobody objects we could discard that backwards compatibility.
>

BTW, what does rescaling do? You're calling two services (2136 and
217302) and then you only take free clusters values from 2136
(rescaling of course) and bsize and blocks from 217302. Why? Can you
please explain me how does rescaling work, and why it is more
relialble than the 'free clusters' reported by 217302?

>
> 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.
>

My patch corrects large free drive space reporting (fat32 drives) both
on Windows and plain DOS. When I say 'corrects' I mean: 'I want
DJGPP's statfs to report the same values that chkdsk reports to avoid
users confusion'

>
> Please say what you expected and what you got. (I suspect the

what I expected from statfs? I expected that it was reporting the
actual number of free clusters, 705145 at this time, instead I'm
getting 655360 on this drive, the other one is reporting 322192 and
chkdsk says 322197...

I suspect (because docs doesn't says anything) that the service 217302
reports the largest block of free clusters, not the actual number of
free clusters, or is that or the service 217302 is buggy on my Windows
version (4.10.1998)


> 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!)

Don't worry, I'll let you know as soon as I can get it working...

>
> > 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!
>

The only documentation I have is from Ralf Brown's Interrupt List
http://www.ctyme.com/rbrown.htm


Best regards,
Norberto

PS: please forgive me for my English, but is really hard (and time
consuming) for me to express in English what I think in Spanish.

- Raw text -