HP-UX 11i and largefiles on rsync 2.6.2

[Steve Bonds]

I've been able to duplicate this problem using the CVS version of rsync
that was current as of about 2000 UTC today (July 27 2004)

This was on an HPUX 11.0 system, not 11i.

When running:

./rsync --archive -v --progress /home/sbonds/bigfile
/home/sbonds/dest_dir/.

I get:

-----
bigfile
rsync: writefd_unbuffered failed to write 32768 bytes: phase "unknown":
Broken pipe (32)
rsync error: error in rsync protocol data stream (code 12) at io.c(902)
-----

When working with GDB to get a backtrace, the third process spawned is the
one that exits.  (On my HPUX system the PIDs are assigned sequentially.
The main rsync is "PID", the sender is "PID+1", and the receiver is
"PID+2".)

The receiver backtrace is:

-----
(gdb) bt
#0  _exit_cleanup (code=11, file=0x56cf0 "receiver.c", line=253)
    at cleanup.c:88
#1  0x9dc0 in receive_data (f_in=0,
    fname_r=0x77ff1a90 "bigfile", fd_r=1,size_r=2147483647,
    fname=0x77ff1a90 "bigfile", fd=4,total_size=2532431502)
    at receiver.c:253
#2  0xac30 in recv_files (f_in=0, flist=0x4000cb50, local_name=0x0)
    at receiver.c:538
#3  0x125b4 in do_recv (f_in=0, f_out=1, flist=0x4000cb50, local_name=0x0)
    at main.c:488
#4  0x129ec in do_server_recv (f_in=0, f_out=1, argc=1, argv=0x77ff085c)
    at main.c:589
#5  0x12b4c in start_server (f_in=0, f_out=1, argc=2, argv=0x77ff0858)
    at main.c:620
#6  0x12a44 in child_main (argc=2, argv=0x77ff0858) at main.c:596
#7  0x2db3c in local_child (argc=2, argv=0x77ff0858, f_in=0x77ff07b8,
    f_out=0x77ff07bc, child_main=0x400050ea <child_main>) at pipe.c:152
#8  0x11e48 in do_cmd (cmd=0x0, machine=0x0, user=0x0,
    path=0x4000bb20 "/home/sbonds/dest_dir/.", f_in=0x77ff07b8,
    f_out=0x77ff07bc) at main.c:332
#9  0x138cc in start_client (argc=1, argv=0x4000b540) at main.c:911
#10 0x13efc in main (argc=2, argv=0x4000b540) at main.c:1112
-----

This was built using CVS version 1.24 of cleanup.c, 1.97 of receiver.c,
and 1.212 of main.c.

-----
$ ./rsync --version
rsync  version 2.6.2  protocol version 28
Copyright (C) 1996-2004 by Andrew Tridgell and others
<http://rsync.samba.org/>
Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles,
              inplace, no IPv6, 32-bit system inums, 64-bit internal inums

rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
are welcome to redistribute it under certain conditions.  See the GNU
General Public Licence for details.
-----

Running "tusc" (HP's system call trace utility, like "truss" on Solaris or
"strace" on Linux) leads me to the following failed system call:

-----
write(4, "> 3 5 1fc85 1a, b4$ ^ \ b2y - d ".., 262144) = 262143
write(4, 0x400a0b37, 1) ......... ERR#27 EFBIG
-----

File descriptor four is the temporary file created by rsync, and "EFBIG"
is "File too large", which the HP man page for write(2) reports as:

-----
[EFBIG]        An attempt was made to write a file that exceeds
               the implementation-dependent maximum file size or
               the process' file size limit.
-----

This is what I would expect to see if the VXFS filesystem was not created
with the "largefiles" option-- but it was.  (And I double-checked.)  Other
utilities (e.g. "dd") can create large files just fine.

I haven't seen anything obviously wrong with write_file or
flush_write_file in fileio.c (v. 1.15).

Do you know what is meant by the "process' file size limit"?

  -- Steve