Date: Sun, 07 Jan 2001 20:52:59 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id: <1438-Sun07Jan2001205258+0200-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6
CC: djgpp-workers AT delorie DOT com, ceo AT nbensacomputers DOT com
In-reply-to: <200101071723.SAA24167@father.ludd.luth.se> (message from Martin
	Str|mberg on Sun, 7 Jan 2001 18:23:02 +0100 (MET))
Subject: Re: df <-> df r:/
References:  <200101071723 DOT SAA24167 AT father DOT ludd DOT luth DOT se>
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

> From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
> Date: Sun, 7 Jan 2001 18:23:02 +0100 (MET)
> 
> I notice that unless the audio disc is playing, it is reported.

Yes.  That's a misfeature, but I couldn't do better without breaking
anything else (some ``solutions'' even break DOS!).

> So I think the right thing to do is mask away bit 9, always.

I have an uneasy feeling, but let's try that and see what, if
anything, breaks.

> \\KANT\TMP           2383668 -3501099  5884767   -146%   k:/
> ...
> 
> But the same df but run as "df k:/" gives:
> Filesystem         1024-blocks  Used Available Capacity Mounted on
> \\KANT\TMP           2383668 1633527   750141     69%   k:/
> 
> When this happen it seems to be like this until I reboot.

What does statfs report in its structure in the case where the
negative number is printed?  (You'd probably need to step with a
debugger into df to see that.)

Do you always see the same negative value?  Are there any special
circumstances that surround the cases where this happen, as opposed to
those when it doesn't happen?

Finally, what is disk k:?  What redirector software does it use?

If only the new `df' has this problem, I'd suspect the FAT32 calls.
Perhaps it would help to disable the FAT32-related calls and see if
the problem goes away.  Or rebuild `df' with stock v2.03 version of
statfs (but all the rest from the current CVS or whatever you were
using until now), and see if something changes.

> And it's only k: that is doing this. I have other shares on the same
> computer and another one, but it's only for k: it's happening.

Is k: particularly large?  Is something special done on it by uits
host computer (the TMP part seems to suggest that it's a scratch
disk?).