From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id: <200101071930.UAA24655@father.ludd.luth.se>
Subject: Re: df <-> df r:/
In-Reply-To: <1438-Sun07Jan2001205258+0200-eliz@is.elta.co.il> from Eli Zaretskii at "Jan 7, 2001 08:52:59 pm"
To: djgpp-workers AT delorie DOT com
Date: Sun, 7 Jan 2001 20:30:29 +0100 (MET)
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

According to Eli Zaretskii:
> > \\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.)

Hmm. I tried some debugging some hours ago. I think is reported _more_
free blocks than total!

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

It change once that I noticed.

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

What WINDOZE is using I don't know but the only protocol I've
installed is TCP/IP and the NetBIOS tab in "TCP/IP properties" has an
"v" for "I want to enable NetBIOS over TCP/IP" and the box is
greyed. Does that answer yuor question?

The servers are running Linux 2.0.something and samba 1.9.something.

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

The only difference between fil316b.zip's df and this is
statfs.c. When I started seeing problems a backed to djlsr203.zip +
the new statfs.c.

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

Not that I can think of. On kant (where k: resides) "df" says:
kant:/tmp> df
Filesystem         1024-blocks  Used Available Capacity Mounted on
/dev/hdb1            2421556 1534313   762050     67%   /x2

Meanwhile, "df" on server (where u: resides) says:
/dev/sdd3            9866249 2055761  7760488     21%   /home

And the TMP part is not because it's tmp but becuase it's my tmp space
for my *DOZE boxes when I want to move things between them or the
Linux boxes. Plus I throw anything I'm considering for later removal
there if I change my mind.


I thought of doing "net use k: /del". Then the negative value moved to
another share on the server server. After I reconnected, the problem
disappeared (from both k: and the other share).


Right,

						MartinS