a daemon. This prevents library functions (such as getopt) stuffing up
our protocol stream when errors are detected.
- defer the error message from the options parsing until after the
socket is multiplexed. This allows clients sending new options which
the remote server doesn't understand to get a sensible error message.
there is then assume that the : is from a filename, not a host:dir
separator. This allows you to copy files with a : in them. (suggestion
from pfeifer@wait.de)
when -p (preserve permissions) isn't set.
It works by taking the sending file permissions and masking them with
the umask to create the destination file permissions. (There is really
no "correct" way of doing this but at least we now behave like GNU cp
which fits the principle of least surprise.)
also fixed a race condition in copy_file()
verbose info not being line buffered to files.
- add a call to localtime() in open_log() in order to prime the C
libraries timezone cache before the chroot(). This should fix the
problem of rsyncd log entries being in GMT time.
significant difference when the transport is ssh as ssh will otherwise
output a complete frame for each checksum record, which increases the
checksum data in size by a factor of around 4.
this prevents a second interrupted transfer from reducing the size of
the transferred file.
- set SIGUSR1 to SIG_IGN early to prevent a race condition that
prevents the --partial code from working properly
patch tries to address the problem in two ways:
1) reinstall the SIGCHLD handler before each fork
2) reap any children not caught by the handler using waitpid with
WNOHANG.
I expect this will fix the problem.
temporary files were being created with the same permissions as the
original file. So if the file was setuid but not owned by the user
doing the transfer then there was a window of opportunity for a
malicious user to execute it with the wrong permissions while it was
being transferred.
Thanks to snabb@epipe.fi for pointing this out.
This bug resulted in rsync being much less efficient that it could be
for files with more than 64k blocks. With the adaptive block size code
giving a maximum block size of 16k this means that files larger than
1GB were handled very inefficiently. The transfer was still accurate,
just slow.