same to bug 1457, on HPUX 11i with ANSI/C compiler with largefile option. below rsync is on local file system. # rsync -av /prod1/* /prod1n/ building file list ... done DW/ DW/DATA/ DW/DATA/DWCOF02.DAT rsync: writefd_unbuffered failed to write 32768 bytes: phase "unknown": Broken pipe rsync error: error in rsync protocol data stream (code 12) at io.c(836) rsync: writefd_unbuffered failed to write 69 bytes: phase "unknown": Broken pipe rsync error: error in rsync protocol data stream (code 12) at io.c(836) # ls -l /prod1/DW/DATA/DWCOF02.DAT -rw-r--r-- 1 dwh dwprod 2225391444 May 31 10:59 /prod1/DW/DATA/DWCOF02.DAT KY
First suggestion: try running the command without the '*' (but with the trailing '/') and see if it still fails. Also, there is a helper script that might help you to debug what is happening: http://rsync.samba.org/rsync-debug Use it in a command like this: rsync -av --rsync-path=/SOME/PATH/rsync-debug localhost:/prod1/* /prod1n/ (Some kind of host: is needed to get rsync to use the rsync-debug script.)
I don't know what the current status of this bug is, but I'm experiencing similar behaviour trying to "emerge sync" with Gentoo's portage. I've seen it on two different machines and only at home .. which may be important because at home I have a commercial Hughes 1.2MB inbound 0.1MB outbound 750ms latency satellite connection. When I bring the laptop to work and connect with a short latency T3 I don't experience the problem. If you need additional info or can suggest useful tests, I'd be happy to play around ..
Created attachment 716 [details] Erroneous attachment This patch separates the daemon-mode's option parsing from the normal client/server's option parsing. It also separates the options in the usage message (requiring the user to use "rsync --daemon --help" to see the daemon options). Lightly tested, including daemon mode over ssh. Need to double-check option parsing separation to ensure I didn't miss anything.
This was probably a case of the mkstemp() function not opening the file with large-file support enabled. The current code attempts to work around this by using mktemp() and a large-file-supporting open() call when it thinks that this is going to be a problem. If you don't believe this analysis to be the case, let me know.