- - Added the --only-write-batch=FILE option that may be used (instead
- of --write-batch=FILE) to create a batch file without doing any
- actual updating of the destination. This allows you to divert all
- the file-updating data away from a slow data link (as long as you
- are pushing the data to the remote server when creating the batch).
-
- - When the generator is taking a long time to fill up its output buffer
- (e.g. if the transferred files are few, small, or missing), it now
- periodically flushes the output buffer so that the sender/receiver
- can get started on the files sooner rather than later.
-
- - Improved the keep-alive code to handle a long silence between the
- sender and the receiver that can occur when the sender is receiving
- the checksum data for a large file.
-
- - Improved the auth-errors that are logged by the daemon to include
- some information on why the authorization failed: wrong user,
- password mismatch, etc. (The client-visible message is unchanged!)
-
- - Improved the client's handling of an "@ERROR" from a daemon so that
- it does not complain about an unexpectedly closed socket (since we
- really did expect the socket to close).
-
- - If the daemon can't open the log-file specified in rsyncd.conf, fall
- back to using syslog and log an appropriate warning. This is better
- than what was typically a totally silent (and fatal) failure (since a
- daemon is not usually run with the --no-detach option that was
- necessary to see the error on stderr).
-
- - The man pages now consistently refer to an rsync daemon as a "daemon"
- instead of a "server" (to distinguish it from the server process in a
- non-daemon transfer).
-
- - Made a small change to the rrsync script (restricted rsync -- in the
- support dir) to make a read-only server reject all --remove-* options
- when sending files (to future-proof it against the possibility of
- other similar options being added at some point).
+ - A new incremental-recursion algorithm is now used when rsync is talking
+ to another 3.0.0 version. This starts the transfer going more quickly
+ (before all the files have been found), and requires much less memory.
+ See the --recursive option in the manpage for some restrictions.
+
+ - The default --delete algorithm is now --delete-during when talking to a
+ 3.x rsync. This is a faster scan than using --delete-before (which is
+ the default when talking to older rsync versions), and is compatible with
+ the new incremental recursion mode.
+
+ - Added the --delete-delay option, which is a more efficient way to delete
+ files at the end of the transfer without needing a separate delete pass.
+
+ - Added the --acls (-A) option to preserve Access Control Lists. This is
+ an improved version of the prior patch that was available. (If you need
+ to have backward compatibility with old, patched versions, the new
+ acls.diff patch that will add that.)
+
+ - Added the --xattrs (-X) option to preserver extended attributes. This is
+ an improved version of the prior patch that was available. (If you need
+ to have backward compatibility with old, patched versions, the new
+ xattrs.diff patch that will add that.)
+
+ - Added the --fake-super option that allows a non-super user to preserve
+ all attributes of a file by using a special extended-attribute idiom.
+ There is also an analogous "fake super" option for an rsync daemon.
+
+ - Added the --iconv option, which allows rsync to convert filenames from
+ one character-set to another during the transfer. (If your system does
+ not support iconv, you must currently manually disable this by using
+ the --enable-iconv configure option.)
+
+ - You may specify --max-delete=0 to a 3.0.0 client as long as the receiving
+ side is at least version 3.0.0. This means that you can pull from an
+ older rsync with this option, but pushing to an older rsync will generate
+ an error. *Be sure to never specify a 0 value to an older rsync client,
+ or it will be silently ignored.*
+
+ - The --hard-link option now uses less memory on both the sending and
+ receiving side for all protocol versions. For protocol 30, the use of a
+ hashtable on the sending side allows us to more efficiently convey to the
+ receiver what files are linked together. This reduces the amount of data
+ sent over the socket by a considerable margin (rather than adding more
+ data), and limits the in-memory storage of the device+inode information
+ to just the sending side for the new protocol 30, or to the receiving
+ side when speaking an older protocol (note that older rsync versions kept
+ the device+inode information on both sides).