Hello Paul,
to make tusc-output a little more readable I removed all the syscalls around lib-loading and gave “du” only a single file:
# ls -als inspection_item.lst
1282246 -rw-r----- 1 xxx xxx 1312994526 Apr 24 01:07 inspection_item.lst
As you can see, HP-UX ls -s outputs 1k blocks while Files on Solaris NFS-Servers and Files on local Volumes are reported in 512 Byte blocks.
the HP-UX /usr/bin/du does the following:
# tusc -f /usr/bin/du -sk inspection_item.lst
...
open("/usr/bin/du", O_RDONLY, 0) ............................................................................ = 3
... (libs read)
open("/usr/lib/hpux32/libc.so.1", O_RDONLY, 0) .............................................................. = 3
open("/usr/lib/hpux32/libdl.so.1", O_RDONLY, 0) ............................................................. = 3
...
lstat64("inspection_item.lst", 0x40010e40) .................................................................. = 0
sysfs(GETFSTYP, 0xa, 0x7ffff180) ............................................................................ = 0
sysfs(GETFSIND, 0x40010400, 0x288) .......................................................................... = 1
sysconf(_SC_CPU_VERSION) .................................................................................... = 768
brk(0x400112d0) ............................................................................................. = 0
brk(0x400132c0) ............................................................................................. = 0
brk(0x40016000) ............................................................................................. = 0
ioctl(1, TCGETA, 0x7ffff150) ................................................................................ = 0
1282222
write(1, "1 2 8 2 2 2 2 ", 7) ............................................................................... = 7
inspection_item.lst
write(1, "\ti n s p e c t i o n _ i t e m ".., 20) .......................................................... = 20
write(1, "\n", 1) ........................................................................................... = 1
exit(0) ..................................................................................................... WIFEXITED(0)
the du on Solaris does “fstatat64()” and afterwards “pathconf(filename, _PC_XATTR_EXISTS)” to find out more, to return the correct values.
the coreutils-du does:
# tusc -f /usr/local/coreutils/bin/du -sk inspection_item.lst
…
open("/usr/local/coreutils/bin/du", O_RDONLY, 0) ............................................................ = 3
… (libs read)
open("/usr/local/lib/hpux32/libintl.so", O_RDONLY, 0) ....................................................... = 3
open("/usr/local/lib/hpux32/libiconv.so", O_RDONLY, 0) ...................................................... = 3
open("/usr/lib/hpux32/libsec.so.1", O_RDONLY, 0) ............................................................ = 3
open("/usr/lib/hpux32/libc.so.1", O_RDONLY, 0) .............................................................. = 3
open("/usr/local/lib/hpux32/libiconv.so", O_RDONLY, 0) ...................................................... = 3
open("/usr/lib/hpux32/libm.so.1", O_RDONLY, 0) .............................................................. = 3
open("/usr/lib/hpux32/libdl.so.1", O_RDONLY, 0) ............................................................. = 3
…
sysconf(_SC_CPU_VERSION) .................................................................................... = 768
…
open("/usr/lib/nls/loc/hpux32/locales.3/C", O_RDONLY, 0) .................................................... ERR#2 ENOENT
…
open(".", O_RDONLY|0x800, 0) ................................................................................ = 3
…
lstat64("inspection_item.lst", 0x40021b70) .................................................................. = 0
brk(0x40030000) ............................................................................................. = 0
brk(0x40032000) ............................................................................................. = 0
ioctl(1, TCGETA, 0x7fffefd0) ................................................................................ = 0
641123
write(1, "6 4 1 1 2 3 ", 6) ................................................................................. = 6
inspection_item.lst
write(1, "\ti n s p e c t i o n _ i t e m ".., 21) .......................................................... = 21
close(1) .................................................................................................... = 0
close(2) .................................................................................................... = 0
exit(0) ..................................................................................................... WIFEXITED(0)
regards,
Andreas
-----Original Message-----
From: Paul Eggert [mailto:eggert@cs.ucla.edu]
Sent: Monday, April 23, 2012 7:14 PM
To: QUITZOW, ANDREAS
Cc: 11316@debbugs.gnu.org
Subject: Re: bug#11316: coreutils 8.16: du
On 04/23/2012 08:09 AM, andreas.quitzow@lhsystems.com wrote:
> for volumes NFS-mounted from HP-UX 11.31 NFS-Servers it shows only
> half the size of /usr/bin/du, where /usr/bin/du is correct.
HP-UX has long had problems with 'du', as described in the coreutils manual. But this particular bug is new.
Can you tell us which system calls coreutils 'du' are invoking, and which that HP-UX 'du' are invoking, by using the 'tusc' tool of HP-UX? That might help us isolate the problem.
Here's where I found a download for 'tusc':
http://hpux.connect.org.uk/hppd/cgi-bin/search?package=&term=/tusc