+This tells you the final file size, that it's 100% complete, the final
+transfer rate for the file, the amount of elapsed time it took to transfer
+the file, and the addition of a total-transfer summary in parentheses.
+These additional numbers tell you how many files have been updated, and
+what percent of the total number of files has been scanned.
+
+dit(bf(-P)) The -P option is equivalent to --partial --progress. Its
+purpose is to make it much easier to specify these two options for a long
+transfer that may be interrupted.
+
+dit(bf(--password-file)) This option allows you to provide a password
+in a file for accessing a remote rsync server. Note that this option
+is only useful when accessing an rsync server using the built in
+transport, not when using a remote shell as the transport. The file
+must not be world readable. It should contain just the password as a
+single line.
+
+dit(bf(--list-only)) This option will cause the source files to be listed
+instead of transferred. This option is inferred if there is no destination
+specified, so you don't usually need to use it explicitly. However, it can
+come in handy for a power user that wants to avoid the "-r --exclude="/*/*"
+options that rsync might use as a compatibility kluge when generating a
+non-recursive listing.
+
+dit(bf(--bwlimit=KBPS)) This option allows you to specify a maximum
+transfer rate in kilobytes per second. This option is most effective when
+using rsync with large files (several megabytes and up). Due to the nature
+of rsync transfers, blocks of data are sent, then if rsync determines the
+transfer was too fast, it will wait before sending the next data block. The
+result is an average transfer rate equaling the specified limit. A value
+of zero specifies no limit.
+
+dit(bf(--write-batch=FILE)) Record a file that can later be applied to
+another identical destination with --read-batch. See the "BATCH MODE"
+section for details.
+
+dit(bf(--read-batch=FILE)) Apply all of the changes stored in FILE, a
+file previously generated by --write-batch.
+If em(FILE) is "-" the batch data will be read from standard input.
+See the "BATCH MODE" section for details.
+
+dit(bf(-4, --ipv4) or bf(-6, --ipv6)) Tells rsync to prefer IPv4/IPv6
+when creating sockets. This only affects sockets that rsync has direct
+control over, such as the outgoing socket when directly contacting an
+rsync daemon. See also these options in the --daemon mode section.
+
+dit(bf(--checksum-seed=NUM)) Set the MD4 checksum seed to the integer
+NUM. This 4 byte checksum seed is included in each block and file
+MD4 checksum calculation. By default the checksum seed is generated
+by the server and defaults to the current time(). This option
+is used to set a specific checksum seed, which is useful for
+applications that want repeatable block and file checksums, or
+in the case where the user wants a more random checksum seed.
+Note that setting NUM to 0 causes rsync to use the default of time()
+for checksum seed.
+
+enddit()
+
+The options allowed when starting an rsync daemon are as follows:
+
+startdit()
+
+dit(bf(--daemon)) This tells rsync that it is to run as a daemon. The
+daemon may be accessed using the bf(host::module) or
+bf(rsync://host/module/) syntax.
+
+If standard input is a socket then rsync will assume that it is being
+run via inetd, otherwise it will detach from the current terminal and
+become a background daemon. The daemon will read the config file
+(rsyncd.conf) on each connect made by a client and respond to
+requests accordingly. See the rsyncd.conf(5) man page for more
+details.
+
+dit(bf(--address)) By default rsync will bind to the wildcard address
+when run as a daemon with the --daemon option or when connecting to a
+rsync server. The --address option allows you to specify a specific IP
+address (or hostname) to bind to. This makes virtual hosting possible
+in conjunction with the --config option. See also the "address" global
+option in the rsyncd.conf manpage.
+
+dit(bf(--bwlimit=KBPS)) This option allows you to specify a maximum
+transfer rate in kilobytes per second for the data the daemon sends.
+The client can still specify a smaller --bwlimit value, but their
+requested value will be rounded down if they try to exceed it. See the
+client version of this option (above) for some extra details.
+
+dit(bf(--config=FILE)) This specifies an alternate config file than
+the default. This is only relevant when --daemon is specified.
+The default is /etc/rsyncd.conf unless the daemon is running over
+a remote shell program and the remote user is not root; in that case
+the default is rsyncd.conf in the current directory (typically $HOME).
+
+dit(bf(--no-detach)) When running as a daemon, this option instructs
+rsync to not detach itself and become a background process. This
+option is required when running as a service on Cygwin, and may also
+be useful when rsync is supervised by a program such as
+bf(daemontools) or AIX's bf(System Resource Controller).
+bf(--no-detach) is also recommended when rsync is run under a
+debugger. This option has no effect if rsync is run from inetd or
+sshd.
+
+dit(bf(--port=PORT)) This specifies an alternate TCP port number for the
+daemon to listen on rather than the default of 873. See also the "port"
+global option in the rsyncd.conf manpage.
+
+dit(bf(-4, --ipv4) or bf(-6, --ipv6)) Tells rsync to prefer IPv4/IPv6
+when creating the incoming sockets that the rsync daemon will use to
+listen for connections. One of these options may be required in older
+versions of Linux to work around an IPv6 bug in the kernel (if you see
+an "address already in use" error when nothing else is using the port,
+try specifying --ipv6 or --ipv4 when starting the daemon).
+
+dit(bf(-h, --help)) When specified after --daemon, print a short help
+page describing the options available for starting an rsync daemon.
+
+enddit()
+
+manpagesection(FILTER RULES)
+
+The filter rules allow for flexible selection of which files to transfer
+(include) and which files to skip (exclude). The rules either directly
+specify include/exclude patterns or they specify a way to acquire more
+include/exclude patterns (e.g. to read them from a file).
+
+As the list of files/directories to transfer is built, rsync checks each
+name to be transferred against the list of include/exclude patterns in
+turn, and the first matching pattern is acted on: if it is an exclude
+pattern, then that file is skipped; if it is an include pattern then that
+filename is not skipped; if no matching pattern is found, then the
+filename is not skipped.
+
+Rsync builds an ordered list of filter rules as specified on the
+command-line. Filter rules have the following syntax:
+
+itemize(
+ it() x RULE
+ it() xMODIFIERS RULE
+ it() !
+)
+
+The 'x' is a single-letter that specifies the kind of rule to create. It
+can have trailing modifiers, and is separated from the RULE by one of the
+following characters: a single space, an equal-sign (=), or an underscore
+(_). Here are the available rule prefixes:
+
+verb(
+ - specifies an exclude pattern.
+ + specifies an include pattern.
+ . specifies a merge-file to read for more rules.
+ : specifies a per-directory merge-file.
+ ! clears the current include/exclude list
+)
+
+Note that the --include/--exclude command-line options do not allow the
+full range of rule parsing as described above -- they only allow the
+specification of include/exclude patterns and the "!" token (not to
+mention the comment lines when reading rules from a file). If a pattern
+does not begin with "- " (dash, space) or "+ " (plus, space), then the
+rule will be interpreted as if "+ " (for an include option) or "- " (for
+an exclude option) were prefixed to the string. A --filter option, on
+the other hand, must always contain one of the prefixes above.
+
+Note also that the --filter, --include, and --exclude options take one
+rule/pattern each. To add multiple ones, you can repeat the options on
+the command-line, use the merge-file syntax of the --filter option, or
+the --include-from/--exclude-from options.
+
+When rules are being read from a file, empty lines are ignored, as are
+comment lines that start with a "#".
+
+manpagesection(INCLUDE/EXCLUDE PATTERN RULES)
+
+You can include and exclude files by specifing patterns using the "+" and
+"-" filter rules (as introduced in the FILTER RULES section above). These
+rules specify a pattern that is matched against the names of the files
+that are going to be transferred. These patterns can take several forms:
+
+itemize(
+
+ it() if the pattern starts with a / then it is anchored to a
+ particular spot in the hierarchy of files, otherwise it is matched
+ against the end of the pathname. This is similar to a leading ^ in
+ regular expressions.
+ Thus "/foo" would match a file called "foo" at either the "root of the
+ transfer" (for a global rule) or in the merge-file's directory (for a
+ per-directory rule).
+ An unqualified "foo" would match any file or directory named "foo"
+ anywhere in the tree because the algorithm is applied recursively from
+ the
+ top down; it behaves as if each path component gets a turn at being the
+ end of the file name. Even the unanchored "sub/foo" would match at
+ any point in the hierarchy where a "foo" was found within a directory
+ named "sub". See the section on ANCHORING INCLUDE/EXCLUDE PATTERNS for
+ a full discussion of how to specify a pattern that matches at the root
+ of the transfer.
+
+ it() if the pattern ends with a / then it will only match a
+ directory, not a file, link, or device.
+
+ it() if the pattern contains a wildcard character from the set
+ *?[ then expression matching is applied using the shell filename
+ matching rules. Otherwise a simple string match is used.
+
+ it() the double asterisk pattern "**" will match slashes while a
+ single asterisk pattern "*" will stop at slashes.
+
+ it() if the pattern contains a / (not counting a trailing /) or a "**"
+ then it is matched against the full pathname, including any leading
+ directories. If the pattern doesn't contain a / or a "**", then it is
+ matched only against the final component of the filename.
+ (Remember that the algorithm is applied recursively so "full filename"
+ can actually be any portion of a path fomr the starting directory on
+ down.)
+
+)
+
+Note that, when using the --recursive (-r) option (which is implied by
+-a), every subcomponent of every path is visited from the top down, so
+include/exclude patterns get applied recursively to each subcomponent's
+full name (e.g. to include "/foo/bar/baz" the subcomponents "/foo" and
+"/foo/bar" must not be excluded).
+The exclude patterns actually short-circuit the directory traversal stage
+when rsync finds the files to send. If a pattern excludes a particular
+parent directory, it can render a deeper include pattern ineffectual
+because rsync did not descend through that excluded section of the
+hierarchy. This is particularly important when using a trailing '*' rule.
+For instance, this won't work:
+
+verb(
+ + /some/path/this-file-will-not-be-found
+ + /file-is-included
+ - *
+)
+
+This fails because the parent directory "some" is excluded by the '*'
+rule, so rsync never visits any of the files in the "some" or "some/path"
+directories. One solution is to ask for all directories in the hierarchy
+to be included by using a single rule: "+_*/" (put it somewhere before the
+"-_*" rule). Another solution is to add specific include rules for all
+the parent dirs that need to be visited. For instance, this set of rules
+works fine:
+
+verb(
+ + /some/
+ + /some/path/
+ + /some/path/this-file-is-found
+ + /file-also-included
+ - *
+)
+
+Here are some examples of exclude/include matching:
+
+itemize(
+ it() "- *.o" would exclude all filenames matching *.o
+ it() "- /foo" would exclude a file called foo in the transfer-root directory
+ it() "- foo/" would exclude any directory called foo
+ it() "- /foo/*/bar" would exclude any file called bar two
+ levels below a directory called foo in the transfer-root directory
+ it() "- /foo/**/bar" would exclude any file called bar two
+ or more levels below a directory called foo in the transfer-root directory
+ it() The combination of "+ */", "+ *.c", and "- *" would include all
+ directories and C source files but nothing else.
+ it() The combination of "+ foo/", "+ foo/bar.c", and "- *" would include
+ only the foo directory and foo/bar.c (the foo directory must be
+ explicitly included or it would be excluded by the "*")
+)
+
+manpagesection(MERGE-FILE FILTER RULES)
+
+You can merge whole files into your filter rules by specifying either a
+"." or a ":" filter rule (as introduced in the FILTER RULES section
+above).
+
+There are two kinds of merged files -- single-instance ('.') and
+per-directory (':'). A single-instance merge file is read one time, and
+its rules are incorporated into the filter list in the place of the "."
+rule. For per-directory merge files, rsync will scan every directory that
+it traverses for the named file, merging its contents when the file exists
+into the current list of inherited rules. These per-directory rule files
+must be created on the sending side because it is the sending side that is
+being scanned for the available files to transfer. These rule files may
+also need to be transferred to the receiving side if you want them to
+affect what files don't get deleted (see PER-DIRECTORY RULES AND DELETE
+below).
+
+Some examples:
+
+verb(
+ . /etc/rsync/default.rules
+ : .per-dir-filter
+ :n- .non-inherited-per-dir-excludes
+)
+
+The following modifiers are accepted after the "." or ":":
+
+itemize(
+ it() A "-" specifies that the file should consist of only exclude
+ patterns, with no other rule-parsing except for the list-clearing
+ token ("!").
+
+ it() A "+" specifies that the file should consist of only include
+ patterns, with no other rule-parsing except for the list-clearing
+ token ("!").
+
+ it() A "C" is a shorthand for the modifiers "sn-", which makes the
+ parsing compatible with the way CVS parses their exclude files. If no
+ filename is specified, ".cvsignore" is assumed.
+
+ it() A "e" will exclude the merge-file from the transfer; e.g.
+ ":e_.rules" is like ":_.rules" and "-_.rules".
+
+ it() An "n" specifies that the rules are not inherited by subdirectories.
+
+ it() An "s" specifies that the rules are split on all whitespace instead
+ of the normal line-splitting. This also turns off comments. Note: the
+ space that separates the prefix from the rule is treated specially, so
+ "- foo + bar" is parsed as two rules (assuming that "-" or "+" was not
+ specified to turn off the parsing of prefixes).
+)
+
+Per-directory rules are inherited in all subdirectories of the directory
+where the merge-file was found unless the 'n' modifier was used. Each
+subdirectory's rules are prefixed to the inherited per-directory rules
+from its parents, which gives the newest rules a higher priority than the
+inherited rules. The entire set of per-dir rules is grouped together in
+the spot where the merge-file was specified, so it is possible to override
+per-dir rules via a rule that got specified earlier in the list of global
+rules. When the list-clearing rule ("!") is read from a per-directory
+file, it only clears the inherited rules for the current merge file.
+
+Another way to prevent a single per-dir rule from being inherited is to
+anchor it with a leading slash. Anchored rules in a per-directory
+merge-file are relative to the merge-file's directory, so a pattern "/foo"
+would only match the file "foo" in the directory where the per-dir filter
+file was found.
+
+Here's an example filter file which you'd specify via --filter=". file":
+
+verb(
+ . /home/user/.global-filter
+ - *.gz
+ : .rules
+ + *.[ch]
+ - *.o
+)
+
+This will merge the contents of the /home/user/.global-filter file at the
+start of the list and also turns the ".rules" filename into a per-directory
+filter file. All rules read-in prior to the start of the directory scan
+follow the global anchoring rules (i.e. a leading slash matches at the root
+of the transfer).
+
+If a per-directory merge-file is specified with a path that is a parent
+directory of the first transfer directory, rsync will scan all the parent
+dirs from that starting point to the transfer directory for the indicated
+per-directory file. For instance, here is a common filter (see -F):
+
+verb(
+ --filter=': /.rsync-filter'
+)
+
+That rule tells rsync to scan for the file .rsync-filter in all
+directories from the root down through the parent directory of the
+transfer prior to the start of the normal directory scan of the file in
+the directories that are sent as a part of the transfer. (Note: for an
+rsync daemon, the root is always the same as the module's "path".)
+
+Some examples of this pre-scanning for per-directory files:
+
+verb(
+ rsync -avF /src/path/ /dest/dir
+ rsync -av --filter=': ../../.rsync-filter' /src/path/ /dest/dir
+ rsync -av --fitler=': .rsync-filter' /src/path/ /dest/dir
+)
+
+The first two commands above will look for ".rsync-filter" in "/" and
+"/src" before the normal scan begins looking for the file in "/src/path"
+and its subdirectories. The last command avoids the parent-dir scan
+and only looks for the ".rsync-filter" files in each directory that is
+a part of the transfer.
+
+If you want to include the contents of a ".cvsignore" in your patterns,
+you should use the rule ":C" -- this is a short-hand for the rule
+":sn-_.cvsignore", and ensures that the .cvsignore file's contents are
+interpreted according to the same parsing rules that CVS uses. You can
+use this to affect where the --cvs-exclude (-C) option's inclusion of the
+per-directory .cvsignore file gets placed into your rules by putting a
+":C" wherever you like in your filter rules. Without this, rsync would
+add the per-dir rule for the .cvignore file at the end of all your other
+rules (giving it a lower priority than your command-line rules). For
+example:
+
+verb(
+ cat <<EOT | rsync -avC --filter='. -' a/ b
+ + foo.o
+ :C
+ - *.old
+ EOT
+
+ rsync -avC --include=foo.o -f :C --exclude='*.old' a/ b
+)
+
+Both of the above rsync commands are identical. Each one will merge all
+the per-directory .cvsignore rules in the middle of the list rather than
+at the end. This allows their dir-specific rules to supersede the rules
+that follow the :C instead of being subservient to all your rules. (The
+global rules taken from the $HOME/.cvsignore file and from $CVSIGNORE are
+not repositioned from their spot at the end of your rules, however -- feel
+free to manually include $HOME/.cvsignore elsewhere in your rules.)
+
+manpagesection(LIST-CLEARING FILTER RULE)
+
+You can clear the current include/exclude list by using the "!" filter
+rule (as introduced in the FILTER RULES section above). The "current"
+list is either the global list of rules (if the rule is encountered while
+parsing the filter options) or a set of per-directory rules (which are
+inherited in their own sub-list, so a subdirectory can use this to clear
+out the parent's rules).
+
+manpagesection(ANCHORING INCLUDE/EXCLUDE PATTERNS)
+
+As mentioned earlier, global include/exclude patterns are anchored at the
+"root of the transfer" (as opposed to per-directory patterns, which are
+anchored at the merge-file's directory). If you think of the transfer as
+a subtree of names that are being sent from sender to receiver, the
+transfer-root is where the tree starts to be duplicated in the destination
+directory. This root governs where patterns that start with a / match.
+
+Because the matching is relative to the transfer-root, changing the
+trailing slash on a source path or changing your use of the --relative
+option affects the path you need to use in your matching (in addition to
+changing how much of the file tree is duplicated on the destination
+host). The following examples demonstrate this.
+
+Let's say that we want to match two source files, one with an absolute
+path of "/home/me/foo/bar", and one with a path of "/home/you/bar/baz".
+Here is how the various command choices differ for a 2-source transfer:
+
+verb(
+ Example cmd: rsync -a /home/me /home/you /dest
+ +/- pattern: /me/foo/bar
+ +/- pattern: /you/bar/baz
+ Target file: /dest/me/foo/bar
+ Target file: /dest/you/bar/baz
+
+ Example cmd: rsync -a /home/me/ /home/you/ /dest
+ +/- pattern: /foo/bar (note missing "me")
+ +/- pattern: /bar/baz (note missing "you")
+ Target file: /dest/foo/bar
+ Target file: /dest/bar/baz
+
+ Example cmd: rsync -a --relative /home/me/ /home/you /dest
+ +/- pattern: /home/me/foo/bar (note full path)
+ +/- pattern: /home/you/bar/baz (ditto)
+ Target file: /dest/home/me/foo/bar
+ Target file: /dest/home/you/bar/baz
+
+ Example cmd: cd /home; rsync -a --relative me/foo you/ /dest
+ +/- pattern: /me/foo/bar (starts at specified path)
+ +/- pattern: /you/bar/baz (ditto)
+ Target file: /dest/me/foo/bar
+ Target file: /dest/you/bar/baz
+)
+
+The easiest way to see what name you should filter is to just
+look at the output when using --verbose and put a / in front of the name
+(use the --dry-run option if you're not yet ready to copy any files).
+
+manpagesection(PER-DIRECTORY RULES AND DELETE)
+
+Without a delete option, per-directory rules are only relevant on the
+sending side, so you can feel free to exclude the merge files themselves
+without affecting the transfer. To make this easy, the 'e' modifier adds
+this exclude for you, as seen in these two equivalent commands:
+
+verb(
+ rsync -av --filter=': .excl' --exclude=.excl host:src/dir /dest
+ rsync -av --filter=':e .excl' host:src/dir /dest
+)
+
+However, if you want to do a delete on the receiving side AND you want some
+files to be excluded from being deleted, you'll need to be sure that the
+receiving side knows what files to exclude. The easiest way is to include
+the per-directory merge files in the transfer and use --delete-after,
+because this ensures that the receiving side gets all the same exclude
+rules as the sending side before it tries to delete anything:
+
+verb(
+ rsync -avF --delete-after host:src/dir /dest
+)
+
+However, if the merge files are not a part of the transfer, you'll need to
+either specify some global exclude rules (i.e. specified on the command
+line), or you'll need to maintain your own per-directory merge files on
+the receiving side. An example of the first is this (assume that the
+remote .rules files exclude themselves):
+
+verb(
+ rsync -av --filter=': .rules' --filter='. /my/extra.rules'
+ --delete host:src/dir /dest
+)
+
+In the above example the extra.rules file can affect both sides of the
+transfer, but (on the sending side) the rules are subservient to the rules
+merged from the .rules files because they were specified after the
+per-directory merge rule.
+
+In one final example, the remote side is excluding the .rsync-filter
+files from the transfer, but we want to use our own .rsync-filter files
+to control what gets deleted on the receiving side. To do this we must
+specifically exclude the per-directory merge files (so that they don't get
+deleted) and then put rules into the local files to control what else
+should not get deleted. Like one of these commands:
+
+verb(
+ rsync -av --filter=':e /.rsync-filter' --delete host:src/dir /dest
+ rsync -avFF --delete host:src/dir /dest
+)
+
+manpagesection(BATCH MODE)
+
+bf(Note:) Batch mode should be considered experimental in this version
+of rsync. The interface and behavior have now stabilized, though, so
+feel free to try this out.
+
+Batch mode can be used to apply the same set of updates to many
+identical systems. Suppose one has a tree which is replicated on a
+number of hosts. Now suppose some changes have been made to this
+source tree and those changes need to be propagated to the other
+hosts. In order to do this using batch mode, rsync is run with the
+write-batch option to apply the changes made to the source tree to one
+of the destination trees. The write-batch option causes the rsync
+client to store in a "batch file" all the information needed to repeat
+this operation against other, identical destination trees.
+
+To apply the recorded changes to another destination tree, run rsync
+with the read-batch option, specifying the name of the same batch
+file, and the destination tree. Rsync updates the destination tree
+using the information stored in the batch file.
+
+For convenience, one additional file is creating when the write-batch
+option is used. This file's name is created by appending
+".sh" to the batch filename. The .sh file contains
+a command-line suitable for updating a destination tree using that
+batch file. It can be executed using a Bourne(-like) shell, optionally
+passing in an alternate destination tree pathname which is then used
+instead of the original path. This is useful when the destination tree
+path differs from the original destination tree path.
+
+Generating the batch file once saves having to perform the file
+status, checksum, and data block generation more than once when
+updating multiple destination trees. Multicast transport protocols can
+be used to transfer the batch update files in parallel to many hosts
+at once, instead of sending the same data to every host individually.
+
+Examples:
+
+verb(
+ $ rsync --write-batch=foo -a host:/source/dir/ /adest/dir/
+ $ scp foo* remote:
+ $ ssh remote ./foo.sh /bdest/dir/
+)
+
+verb(
+ $ rsync --write-batch=foo -a /source/dir/ /adest/dir/
+ $ ssh remote rsync --read-batch=- -a /bdest/dir/ <foo
+)
+
+In these examples, rsync is used to update /adest/dir/ from /source/dir/
+and the information to repeat this operation is stored in "foo" and
+"foo.sh". The host "remote" is then updated with the batched data going
+into the directory /bdest/dir. The differences between the two examples
+reveals some of the flexibility you have in how you deal with batches:
+
+itemize(
+
+ it() The first example shows that the initial copy doesn't have to be
+ local -- you can push or pull data to/from a remote host using either the
+ remote-shell syntax or rsync daemon syntax, as desired.
+
+ it() The first example uses the created "foo.sh" file to get the right
+ rsync options when running the read-batch command on the remote host.
+
+ it() The second example reads the batch data via standard input so that
+ the batch file doesn't need to be copied to the remote machine first.
+ This example avoids the foo.sh script because it needed to use a modified
+ --read-batch option, but you could edit the script file if you wished to
+ make use of it (just be sure that no other option is trying to use
+ standard input, such as the "--exclude-from=-" option).
+
+)
+
+Caveats:
+
+The read-batch option expects the destination tree that it is updating
+to be identical to the destination tree that was used to create the
+batch update fileset. When a difference between the destination trees
+is encountered the update might be discarded with no error (if the file
+appears to be up-to-date already) or the file-update may be attempted
+and then, if the file fails to verify, the update discarded with an
+error. This means that it should be safe to re-run a read-batch operation
+if the command got interrupted. If you wish to force the batched-update to
+always be attempted regardless of the file's size and date, use the -I
+option (when reading the batch).
+If an error occurs, the destination tree will probably be in a
+partially updated state. In that case, rsync can
+be used in its regular (non-batch) mode of operation to fix up the
+destination tree.
+
+The rsync version used on all destinations must be at least as new as the
+one used to generate the batch file. Rsync will die with an error if the
+protocol version in the batch file is too new for the batch-reading rsync
+to handle.
+
+The --dry-run (-n) option does not work in batch mode and yields a runtime
+error.
+
+When reading a batch file, rsync will force the value of certain options
+to match the data in the batch file if you didn't set them to the same
+as the batch-writing command. Other options can (and should) be changed.
+For instance
+--write-batch changes to --read-batch, --files-from is dropped, and the
+--include/--exclude options are not needed unless --delete is specified
+without --delete-excluded.
+
+The code that creates the BATCH.sh file transforms any include/exclude
+options into a single list that is appended as a "here" document to the
+shell script file. An advanced user can use this to modify the exclude
+list if a change in what gets deleted by --delete is desired. A normal
+user can ignore this detail and just use the shell script as an easy way
+to run the appropriate --read-batch command for the batched data.
+
+The original batch mode in rsync was based on "rsync+", but the latest
+version uses a new implementation.
+
+manpagesection(SYMBOLIC LINKS)
+
+Three basic behaviors are possible when rsync encounters a symbolic
+link in the source directory.
+
+By default, symbolic links are not transferred at all. A message
+"skipping non-regular" file is emitted for any symlinks that exist.
+
+If bf(--links) is specified, then symlinks are recreated with the same
+target on the destination. Note that bf(--archive) implies
+bf(--links).
+
+If bf(--copy-links) is specified, then symlinks are "collapsed" by
+copying their referent, rather than the symlink.
+
+rsync also distinguishes "safe" and "unsafe" symbolic links. An
+example where this might be used is a web site mirror that wishes
+ensure the rsync module they copy does not include symbolic links to
+bf(/etc/passwd) in the public section of the site. Using
+bf(--copy-unsafe-links) will cause any links to be copied as the file
+they point to on the destination. Using bf(--safe-links) will cause
+unsafe links to be omitted altogether.
+
+Symbolic links are considered unsafe if they are absolute symlinks
+(start with bf(/)), empty, or if they contain enough bf("..")
+components to ascend from the directory being copied.
+
+manpagesection(DIAGNOSTICS)
+
+rsync occasionally produces error messages that may seem a little
+cryptic. The one that seems to cause the most confusion is "protocol
+version mismatch - is your shell clean?".
+
+This message is usually caused by your startup scripts or remote shell
+facility producing unwanted garbage on the stream that rsync is using
+for its transport. The way to diagnose this problem is to run your
+remote shell like this:
+
+verb(
+ ssh remotehost /bin/true > out.dat
+)
+
+then look at out.dat. If everything is working correctly then out.dat
+should be a zero length file. If you are getting the above error from
+rsync then you will probably find that out.dat contains some text or
+data. Look at the contents and try to work out what is producing
+it. The most common cause is incorrectly configured shell startup
+scripts (such as .cshrc or .profile) that contain output statements
+for non-interactive logins.
+
+If you are having trouble debugging filter patterns, then
+try specifying the -vv option. At this level of verbosity rsync will
+show why each individual file is included or excluded.
+
+manpagesection(EXIT VALUES)
+
+startdit()
+dit(bf(0)) Success
+dit(bf(1)) Syntax or usage error
+dit(bf(2)) Protocol incompatibility
+dit(bf(3)) Errors selecting input/output files, dirs
+dit(bf(4)) Requested action not supported: an attempt
+was made to manipulate 64-bit files on a platform that cannot support
+them; or an option was specified that is supported by the client and
+not by the server.
+dit(bf(5)) Error starting client-server protocol
+dit(bf(10)) Error in socket I/O
+dit(bf(11)) Error in file I/O
+dit(bf(12)) Error in rsync protocol data stream
+dit(bf(13)) Errors with program diagnostics
+dit(bf(14)) Error in IPC code
+dit(bf(20)) Received SIGUSR1 or SIGINT
+dit(bf(21)) Some error returned by waitpid()
+dit(bf(22)) Error allocating core memory buffers
+dit(bf(23)) Partial transfer due to error
+dit(bf(24)) Partial transfer due to vanished source files
+dit(bf(30)) Timeout in data send/receive
+enddit()
+
+manpagesection(ENVIRONMENT VARIABLES)
+
+startdit()
+
+dit(bf(CVSIGNORE)) The CVSIGNORE environment variable supplements any
+ignore patterns in .cvsignore files. See the --cvs-exclude option for
+more details.
+
+dit(bf(RSYNC_RSH)) The RSYNC_RSH environment variable allows you to
+override the default shell used as the transport for rsync. Command line
+options are permitted after the command name, just as in the -e option.
+
+dit(bf(RSYNC_PROXY)) The RSYNC_PROXY environment variable allows you to
+redirect your rsync client to use a web proxy when connecting to a
+rsync daemon. You should set RSYNC_PROXY to a hostname:port pair.
+
+dit(bf(RSYNC_PASSWORD)) Setting RSYNC_PASSWORD to the required
+password allows you to run authenticated rsync connections to an rsync
+daemon without user intervention. Note that this does not supply a
+password to a shell transport such as ssh.
+
+dit(bf(USER) or bf(LOGNAME)) The USER or LOGNAME environment variables
+are used to determine the default username sent to an rsync server.
+If neither is set, the username defaults to "nobody".
+
+dit(bf(HOME)) The HOME environment variable is used to find the user's
+default .cvsignore file.