Mail Archives: djgpp-workers/2001/01/07/14:30:37
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
- Raw text -