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 Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Systems Aktiengesellschaft, Kelsterbach, Registereintragung / Registration: Amtsgericht Darmstadt 84307 Vorsitzender des Aufsichtsrats / Chairman of the Supervisory Board: Stephan Gemkow Vorstand / Executive Board: Stefan Hansen (Vorsitzender / Chairman), Dr. Gunter Kuechler -----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://h21007.www2.hp.com/portal/site/dspp/PAGE.template/page.document?c iid=61086d6e1de021106d6e1de02110275d6e10RCRD http://hpux.connect.org.uk/hppd/cgi-bin/search?package=&term=/tusc