du(1) returns funny sizes

[David Barts]

We have two systems, a Solbourne 4/600 (rabbit) and an HP9000/370
(pacer).  Both systems have each other's filesystems mounted via
NFS.

Yesterday, I noticed that du(1) was reporting funny values when run
on a remote directory.  For example (this is a directory on the HP):

	rabbit% /usr/5bin/du /d0/users/davidb/misc
	1417    /d0/users/davidb/misc

	pacer% du /d0/users/davidb/misc
	2834  /d0/users/davidb/misc

As you can see, running du on the remote system reports only half
as many blocks as there really are.  The reverse is true if we
run du on a Solbourne directory--du reports the correct number
of blocks on the Solbourne, but reports twice as many as there
really are when run from the HP.

This looks like a du bug (or feature :-) ), because only du is
affected.  Some experimenting with trace(1) on the Solbourne shows that
du apparently calculates disk usage by doing an lstat(2) of everything
in the directory tree, and totaling up st_size.

Experimentation shows lstat(2) always returns the same values for the
same file *, regardless of what system the lstat() call is issued from
or where the lstat()ed file resides.  If it were an NFS configuration
problem, one would expect lstat(2) to report bogus sizes and everything
that calls lstat() would be affected.  This is why it looks like a du
bug to me.

* Except for st_dev (which is to be expected).

The Solbourne is running OS/MP 4.0C_Export; the HP is running HP-UX
6.5. All filesystems on the HP are long file name (BSD-style) format.
Even though I just noticed the problem yesterday, I believe it has been
with us all along and nobody has notived it until now.

Reply to me and I will summarize...
-- 
David Barts			Pacer Corporation, Bothell, WA
davidb at pacer.uucp		...!uunet!pilchuck!pacer!davidb