summaryrefslogtreecommitdiffstats
path: root/rsync.1
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-17 16:14:31 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-17 16:14:31 +0000
commit2d5707c7479eacb3b1ad98e01b53f56a88f8fb78 (patch)
treed9c334e83692851c02e3e1b8e65570c97bc82481 /rsync.1
parentInitial commit. (diff)
downloadrsync-2d5707c7479eacb3b1ad98e01b53f56a88f8fb78.tar.xz
rsync-2d5707c7479eacb3b1ad98e01b53f56a88f8fb78.zip
Adding upstream version 3.2.7.upstream/3.2.7
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to '')
-rw-r--r--rsync.15051
-rw-r--r--rsync.1.html4511
-rw-r--r--rsync.1.md4842
3 files changed, 14404 insertions, 0 deletions
diff --git a/rsync.1 b/rsync.1
new file mode 100644
index 0000000..66a2da3
--- /dev/null
+++ b/rsync.1
@@ -0,0 +1,5051 @@
+.TH "rsync" "1" "20 Oct 2022" "rsync 3.2.7" "User Commands"
+.\" prefix=/usr
+.P
+.SH "NAME"
+.P
+rsync \- a fast, versatile, remote (and local) file-copying tool
+.P
+.SH "SYNOPSIS"
+.P
+.nf
+Local:
+ rsync [OPTION...] SRC... [DEST]
+
+Access via remote shell:
+ Pull:
+ rsync [OPTION...] [USER@]HOST:SRC... [DEST]
+ Push:
+ rsync [OPTION...] SRC... [USER@]HOST:DEST
+
+Access via rsync daemon:
+ Pull:
+ rsync [OPTION...] [USER@]HOST::SRC... [DEST]
+ rsync [OPTION...] rsync://[USER@]HOST[:PORT]/SRC... [DEST]
+ Push:
+ rsync [OPTION...] SRC... [USER@]HOST::DEST
+ rsync [OPTION...] SRC... rsync://[USER@]HOST[:PORT]/DEST)
+.fi
+.P
+Usages with just one SRC arg and no DEST arg will list the source files instead
+of copying.
+.P
+The online version of this manpage (that includes cross-linking of topics)
+is available at https://download.samba.org/pub/rsync/rsync.1.
+.P
+.SH "DESCRIPTION"
+.P
+Rsync is a fast and extraordinarily versatile file copying tool. It can copy
+locally, to/from another host over any remote shell, or to/from a remote rsync
+daemon. It offers a large number of options that control every aspect of its
+behavior and permit very flexible specification of the set of files to be
+copied. It is famous for its delta-transfer algorithm, which reduces the
+amount of data sent over the network by sending only the differences between
+the source files and the existing files in the destination. Rsync is widely
+used for backups and mirroring and as an improved copy command for everyday
+use.
+.P
+Rsync finds files that need to be transferred using a "quick check" algorithm
+(by default) that looks for files that have changed in size or in last-modified
+time. Any changes in the other preserved attributes (as requested by options)
+are made on the destination file directly when the quick check indicates that
+the file's data does not need to be updated.
+.P
+Some of the additional features of rsync are:
+.P
+.IP o
+support for copying links, devices, owners, groups, and permissions
+.IP o
+exclude and exclude-from options similar to GNU tar
+.IP o
+a CVS exclude mode for ignoring the same files that CVS would ignore
+.IP o
+can use any transparent remote shell, including ssh or rsh
+.IP o
+does not require super-user privileges
+.IP o
+pipelining of file transfers to minimize latency costs
+.IP o
+support for anonymous or authenticated rsync daemons (ideal for mirroring)
+.P
+.SH "GENERAL"
+.P
+Rsync copies files either to or from a remote host, or locally on the current
+host (it does not support copying files between two remote hosts).
+.P
+There are two different ways for rsync to contact a remote system: using a
+remote-shell program as the transport (such as ssh or rsh) or contacting an
+rsync daemon directly via TCP. The remote-shell transport is used whenever the
+source or destination path contains a single colon (:) separator after a host
+specification. Contacting an rsync daemon directly happens when the source or
+destination path contains a double colon (::) separator after a host
+specification, OR when an rsync:// URL is specified (see also the USING
+RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTION section for an
+exception to this latter rule).
+.P
+As a special case, if a single source arg is specified without a destination,
+the files are listed in an output format similar to "\fBls\ \-l\fP".
+.P
+As expected, if neither the source or destination path specify a remote host,
+the copy occurs locally (see also the \fB\-\-list-only\fP option).
+.P
+Rsync refers to the local side as the client and the remote side as the server.
+Don't confuse server with an rsync daemon. A daemon is always a server, but a
+server can be either a daemon or a remote-shell spawned process.
+.P
+.SH "SETUP"
+.P
+See the file README.md for installation instructions.
+.P
+Once installed, you can use rsync to any machine that you can access via a
+remote shell (as well as some that you can access using the rsync daemon-mode
+protocol). For remote transfers, a modern rsync uses ssh for its
+communications, but it may have been configured to use a different remote shell
+by default, such as rsh or remsh.
+.P
+You can also specify any remote shell you like, either by using the \fB\-e\fP
+command line option, or by setting the \fBRSYNC_RSH\fP environment variable.
+.P
+Note that rsync must be installed on both the source and destination machines.
+.P
+.SH "USAGE"
+.P
+You use rsync in the same way you use rcp. You must specify a source and a
+destination, one of which may be remote.
+.P
+Perhaps the best way to explain the syntax is with some examples:
+.RS 4
+.P
+.nf
+rsync -t *.c foo:src/
+.fi
+.RE
+.P
+This would transfer all files matching the pattern \fB*.c\fP from the current
+directory to the directory src on the machine foo. If any of the files already
+exist on the remote system then the rsync remote-update protocol is used to
+update the file by sending only the differences in the data. Note that the
+expansion of wildcards on the command-line (\fB*.c\fP) into a list of files is
+handled by the shell before it runs rsync and not by rsync itself (exactly the
+same as all other Posix-style programs).
+.RS 4
+.P
+.nf
+rsync -avz foo:src/bar /data/tmp
+.fi
+.RE
+.P
+This would recursively transfer all files from the directory src/bar on the
+machine foo into the /data/tmp/bar directory on the local machine. The files
+are transferred in archive mode, which ensures that symbolic links, devices,
+attributes, permissions, ownerships, etc. are preserved in the transfer.
+Additionally, compression will be used to reduce the size of data portions of
+the transfer.
+.RS 4
+.P
+.nf
+rsync -avz foo:src/bar/ /data/tmp
+.fi
+.RE
+.P
+A trailing slash on the source changes this behavior to avoid creating an
+additional directory level at the destination. You can think of a trailing /
+on a source as meaning "copy the contents of this directory" as opposed to
+"copy the directory by name", but in both cases the attributes of the
+containing directory are transferred to the containing directory on the
+destination. In other words, each of the following commands copies the files
+in the same way, including their setting of the attributes of /dest/foo:
+.RS 4
+.P
+.nf
+rsync -av /src/foo /dest
+rsync -av /src/foo/ /dest/foo
+.fi
+.RE
+.P
+Note also that host and module references don't require a trailing slash to
+copy the contents of the default directory. For example, both of these copy
+the remote directory's contents into "/dest":
+.RS 4
+.P
+.nf
+rsync -av host: /dest
+rsync -av host::module /dest
+.fi
+.RE
+.P
+You can also use rsync in local-only mode, where both the source and
+destination don't have a ':' in the name. In this case it behaves like an
+improved copy command.
+.P
+Finally, you can list all the (listable) modules available from a particular
+rsync daemon by leaving off the module name:
+.RS 4
+.P
+.nf
+rsync somehost.mydomain.com::
+.fi
+.RE
+.P
+.SH "COPYING TO A DIFFERENT NAME"
+.P
+When you want to copy a directory to a different name, use a trailing slash on
+the source directory to put the contents of the directory into any destination
+directory you like:
+.RS 4
+.P
+.nf
+rsync -ai foo/ bar/
+.fi
+.RE
+.P
+Rsync also has the ability to customize a destination file's name when copying
+a single item. The rules for this are:
+.P
+.IP o
+The transfer list must consist of a single item (either a file or an empty
+directory)
+.IP o
+The final element of the destination path must not exist as a directory
+.IP o
+The destination path must not have been specified with a trailing slash
+.P
+Under those circumstances, rsync will set the name of the destination's single
+item to the last element of the destination path. Keep in mind that it is best
+to only use this idiom when copying a file and use the above trailing-slash
+idiom when copying a directory.
+.P
+The following example copies the \fBfoo.c\fP file as \fBbar.c\fP in the \fBsave\fP dir
+(assuming that \fBbar.c\fP isn't a directory):
+.RS 4
+.P
+.nf
+rsync -ai src/foo.c save/bar.c
+.fi
+.RE
+.P
+The single-item copy rule might accidentally bite you if you unknowingly copy a
+single item and specify a destination dir that doesn't exist (without using a
+trailing slash). For example, if \fBsrc/*.c\fP matches one file and \fBsave/dir\fP
+doesn't exist, this will confuse you by naming the destination file \fBsave/dir\fP:
+.RS 4
+.P
+.nf
+rsync -ai src/*.c save/dir
+.fi
+.RE
+.P
+To prevent such an accident, either make sure the destination dir exists or
+specify the destination path with a trailing slash:
+.RS 4
+.P
+.nf
+rsync -ai src/*.c save/dir/
+.fi
+.RE
+.P
+.SH "SORTED TRANSFER ORDER"
+.P
+Rsync always sorts the specified filenames into its internal transfer list.
+This handles the merging together of the contents of identically named
+directories, makes it easy to remove duplicate filenames. It can, however,
+confuse someone when the files are transferred in a different order than what
+was given on the command-line.
+.P
+If you need a particular file to be transferred prior to another, either
+separate the files into different rsync calls, or consider using
+\fB\-\-delay-updates\fP (which doesn't affect the sorted transfer order, but
+does make the final file-updating phase happen much more rapidly).
+.P
+.SH "MULTI-HOST SECURITY"
+.P
+Rsync takes steps to ensure that the file requests that are shared in a
+transfer are protected against various security issues. Most of the potential
+problems arise on the receiving side where rsync takes steps to ensure that the
+list of files being transferred remains within the bounds of what was
+requested.
+.P
+Toward this end, rsync 3.1.2 and later have aborted when a file list contains
+an absolute or relative path that tries to escape out of the top of the
+transfer. Also, beginning with version 3.2.5, rsync does two more safety
+checks of the file list to (1) ensure that no extra source arguments were added
+into the transfer other than those that the client requested and (2) ensure
+that the file list obeys the exclude rules that were sent to the sender.
+.P
+For those that don't yet have a 3.2.5 client rsync (or those that want to be
+extra careful), it is safest to do a copy into a dedicated destination
+directory for the remote files when you don't trust the remote host. For
+example, instead of doing an rsync copy into your home directory:
+.RS 4
+.P
+.nf
+rsync -aiv host1:dir1 ~
+.fi
+.RE
+.P
+Dedicate a "host1-files" dir to the remote content:
+.RS 4
+.P
+.nf
+rsync -aiv host1:dir1 ~/host1-files
+.fi
+.RE
+.P
+See the \fB\-\-trust-sender\fP option for additional details.
+.P
+CAUTION: it is not particularly safe to use rsync to copy files from a
+case-preserving filesystem to a case-ignoring filesystem. If you must perform
+such a copy, you should either disable symlinks via \fB\-\-no-links\fP or enable the
+munging of symlinks via \fB\-\-munge-links\fP (and make sure you use the
+right local or remote option). This will prevent rsync from doing potentially
+dangerous things if a symlink name overlaps with a file or directory. It does
+not, however, ensure that you get a full copy of all the files (since that may
+not be possible when the names overlap). A potentially better solution is to
+list all the source files and create a safe list of filenames that you pass to
+the \fB\-\-files-from\fP option. Any files that conflict in name would need
+to be copied to different destination directories using more than one copy.
+.P
+While a copy of a case-ignoring filesystem to a case-ignoring filesystem can
+work out fairly well, if no \fB\-\-delete-during\fP or \fB\-\-delete-before\fP option is
+active, rsync can potentially update an existing file on the receiveing side
+without noticing that the upper-/lower-case of the filename should be changed
+to match the sender.
+.P
+.SH "ADVANCED USAGE"
+.P
+The syntax for requesting multiple files from a remote host is done by
+specifying additional remote-host args in the same style as the first, or with
+the hostname omitted. For instance, all these work:
+.RS 4
+.P
+.nf
+rsync -aiv host:file1 :file2 host:file{3,4} /dest/
+rsync -aiv host::modname/file{1,2} host::modname/extra /dest/
+rsync -aiv host::modname/first ::extra-file{1,2} /dest/
+.fi
+.RE
+.P
+Note that a daemon connection only supports accessing one module per copy
+command, so if the start of a follow-up path doesn't begin with the
+modname of the first path, it is assumed to be a path in the module (such as
+the extra-file1 & extra-file2 that are grabbed above).
+.P
+Really old versions of rsync (2.6.9 and before) only allowed specifying one
+remote-source arg, so some people have instead relied on the remote-shell
+performing space splitting to break up an arg into multiple paths. Such
+unintuitive behavior is no longer supported by default (though you can request
+it, as described below).
+.P
+Starting in 3.2.4, filenames are passed to a remote shell in such a way as to
+preserve the characters you give it. Thus, if you ask for a file with spaces
+in the name, that's what the remote rsync looks for:
+.RS 4
+.P
+.nf
+rsync -aiv host:'a simple file.pdf' /dest/
+.fi
+.RE
+.P
+If you use scripts that have been written to manually apply extra quoting to
+the remote rsync args (or to require remote arg splitting), you can ask rsync
+to let your script handle the extra escaping. This is done by either adding
+the \fB\-\-old-args\fP option to the rsync runs in the script (which requires
+a new rsync) or exporting RSYNC_OLD_ARGS=1 and RSYNC_PROTECT_ARGS=0
+(which works with old or new rsync versions).
+.P
+.SH "CONNECTING TO AN RSYNC DAEMON"
+.P
+It is also possible to use rsync without a remote shell as the transport. In
+this case you will directly connect to a remote rsync daemon, typically using
+TCP port 873. (This obviously requires the daemon to be running on the remote
+system, so refer to the STARTING AN RSYNC DAEMON TO ACCEPT CONNECTIONS
+section below for information on that.)
+.P
+Using rsync in this way is the same as using it with a remote shell except
+that:
+.P
+.IP o
+Use either double-colon syntax or rsync:// URL syntax instead of the
+single-colon (remote shell) syntax.
+.IP o
+The first element of the "path" is actually a module name.
+.IP o
+Additional remote source args can use an abbreviated syntax that omits the
+hostname and/or the module name, as discussed in ADVANCED USAGE.
+.IP o
+The remote daemon may print a "message of the day" when you connect.
+.IP o
+If you specify only the host (with no module or path) then a list of
+accessible modules on the daemon is output.
+.IP o
+If you specify a remote source path but no destination, a listing of the
+matching files on the remote daemon is output.
+.IP o
+The \fB\-\-rsh\fP (\fB\-e\fP) option must be omitted to avoid changing the
+connection style from using a socket connection to USING RSYNC-DAEMON
+FEATURES VIA A REMOTE-SHELL CONNECTION.
+.P
+An example that copies all the files in a remote module named "src":
+.RS 4
+.P
+.nf
+rsync -av host::src /dest
+.fi
+.RE
+.P
+Some modules on the remote daemon may require authentication. If so, you will
+receive a password prompt when you connect. You can avoid the password prompt
+by setting the environment variable \fBRSYNC_PASSWORD\fP to the password you
+want to use or using the \fB\-\-password-file\fP option. This may be useful
+when scripting rsync.
+.P
+WARNING: On some systems environment variables are visible to all users. On
+those systems using \fB\-\-password-file\fP is recommended.
+.P
+You may establish the connection via a web proxy by setting the environment
+variable \fBRSYNC_PROXY\fP to a hostname:port pair pointing to your web proxy.
+Note that your web proxy's configuration must support proxy connections to port
+873.
+.P
+You may also establish a daemon connection using a program as a proxy by
+setting the environment variable \fBRSYNC_CONNECT_PROG\fP to the commands you
+wish to run in place of making a direct socket connection. The string may
+contain the escape "%H" to represent the hostname specified in the rsync
+command (so use "%%" if you need a single "%" in your string). For example:
+.RS 4
+.P
+.nf
+export RSYNC_CONNECT_PROG='ssh proxyhost nc %H 873'
+rsync -av targethost1::module/src/ /dest/
+rsync -av rsync://targethost2/module/src/ /dest/
+.fi
+.RE
+.P
+The command specified above uses ssh to run nc (netcat) on a proxyhost, which
+forwards all data to port 873 (the rsync daemon) on the targethost (%H).
+.P
+Note also that if the \fBRSYNC_SHELL\fP environment variable is set, that
+program will be used to run the \fBRSYNC_CONNECT_PROG\fP command instead of using
+the default shell of the \fBsystem()\fP call.
+.P
+.SH "USING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTION"
+.P
+It is sometimes useful to use various features of an rsync daemon (such as
+named modules) without actually allowing any new socket connections into a
+system (other than what is already required to allow remote-shell access).
+Rsync supports connecting to a host using a remote shell and then spawning a
+single-use "daemon" server that expects to read its config file in the home dir
+of the remote user. This can be useful if you want to encrypt a daemon-style
+transfer's data, but since the daemon is started up fresh by the remote user,
+you may not be able to use features such as chroot or change the uid used by
+the daemon. (For another way to encrypt a daemon transfer, consider using ssh
+to tunnel a local port to a remote machine and configure a normal rsync daemon
+on that remote host to only allow connections from "localhost".)
+.P
+From the user's perspective, a daemon transfer via a remote-shell connection
+uses nearly the same command-line syntax as a normal rsync-daemon transfer,
+with the only exception being that you must explicitly set the remote shell
+program on the command-line with the \fB\-\-rsh=COMMAND\fP option. (Setting the
+RSYNC_RSH in the environment will not turn on this functionality.) For example:
+.RS 4
+.P
+.nf
+rsync -av --rsh=ssh host::module /dest
+.fi
+.RE
+.P
+If you need to specify a different remote-shell user, keep in mind that the
+user@ prefix in front of the host is specifying the rsync-user value (for a
+module that requires user-based authentication). This means that you must give
+the '\-l user' option to ssh when specifying the remote-shell, as in this
+example that uses the short version of the \fB\-\-rsh\fP option:
+.RS 4
+.P
+.nf
+rsync -av -e "ssh -l ssh-user" rsync-user@host::module /dest
+.fi
+.RE
+.P
+The "ssh-user" will be used at the ssh level; the "rsync-user" will be used to
+log-in to the "module".
+.P
+In this setup, the daemon is started by the ssh command that is accessing the
+system (which can be forced via the \fB~/.ssh/authorized_keys\fP file, if desired).
+However, when accessing a daemon directly, it needs to be started beforehand.
+.P
+.SH "STARTING AN RSYNC DAEMON TO ACCEPT CONNECTIONS"
+.P
+In order to connect to an rsync daemon, the remote system needs to have a
+daemon already running (or it needs to have configured something like inetd to
+spawn an rsync daemon for incoming connections on a particular port). For full
+information on how to start a daemon that will handling incoming socket
+connections, see the \fBrsyncd.conf\fP(5) manpage\ \-\- that is
+the config file for the daemon, and it contains the full details for how to run
+the daemon (including stand-alone and inetd configurations).
+.P
+If you're using one of the remote-shell transports for the transfer, there is
+no need to manually start an rsync daemon.
+.P
+.SH "EXAMPLES"
+.P
+Here are some examples of how rsync can be used.
+.P
+To backup a home directory, which consists of large MS Word files and mail
+folders, a per-user cron job can be used that runs this each day:
+.RS 4
+.P
+.nf
+rsync -aiz . bkhost:backup/joe/
+.fi
+.RE
+.P
+To move some files from a remote host to the local host, you could run:
+.RS 4
+.P
+.nf
+rsync -aiv --remove-source-files rhost:/tmp/{file1,file2}.c ~/src/
+.fi
+.RE
+.P
+.SH "OPTION SUMMARY"
+.P
+Here is a short summary of the options available in rsync. Each option also
+has its own detailed description later in this manpage.
+.P
+.nf
+--verbose, -v increase verbosity
+--info=FLAGS fine-grained informational verbosity
+--debug=FLAGS fine-grained debug verbosity
+--stderr=e|a|c change stderr output mode (default: errors)
+--quiet, -q suppress non-error messages
+--no-motd suppress daemon-mode MOTD
+--checksum, -c skip based on checksum, not mod-time & size
+--archive, -a archive mode is -rlptgoD (no -A,-X,-U,-N,-H)
+--no-OPTION turn off an implied OPTION (e.g. --no-D)
+--recursive, -r recurse into directories
+--relative, -R use relative path names
+--no-implied-dirs don't send implied dirs with --relative
+--backup, -b make backups (see --suffix & --backup-dir)
+--backup-dir=DIR make backups into hierarchy based in DIR
+--suffix=SUFFIX backup suffix (default ~ w/o --backup-dir)
+--update, -u skip files that are newer on the receiver
+--inplace update destination files in-place
+--append append data onto shorter files
+--append-verify --append w/old data in file checksum
+--dirs, -d transfer directories without recursing
+--old-dirs, --old-d works like --dirs when talking to old rsync
+--mkpath create destination's missing path components
+--links, -l copy symlinks as symlinks
+--copy-links, -L transform symlink into referent file/dir
+--copy-unsafe-links only "unsafe" symlinks are transformed
+--safe-links ignore symlinks that point outside the tree
+--munge-links munge symlinks to make them safe & unusable
+--copy-dirlinks, -k transform symlink to dir into referent dir
+--keep-dirlinks, -K treat symlinked dir on receiver as dir
+--hard-links, -H preserve hard links
+--perms, -p preserve permissions
+--executability, -E preserve executability
+--chmod=CHMOD affect file and/or directory permissions
+--acls, -A preserve ACLs (implies --perms)
+--xattrs, -X preserve extended attributes
+--owner, -o preserve owner (super-user only)
+--group, -g preserve group
+--devices preserve device files (super-user only)
+--copy-devices copy device contents as a regular file
+--write-devices write to devices as files (implies --inplace)
+--specials preserve special files
+-D same as --devices --specials
+--times, -t preserve modification times
+--atimes, -U preserve access (use) times
+--open-noatime avoid changing the atime on opened files
+--crtimes, -N preserve create times (newness)
+--omit-dir-times, -O omit directories from --times
+--omit-link-times, -J omit symlinks from --times
+--super receiver attempts super-user activities
+--fake-super store/recover privileged attrs using xattrs
+--sparse, -S turn sequences of nulls into sparse blocks
+--preallocate allocate dest files before writing them
+--dry-run, -n perform a trial run with no changes made
+--whole-file, -W copy files whole (w/o delta-xfer algorithm)
+--checksum-choice=STR choose the checksum algorithm (aka --cc)
+--one-file-system, -x don't cross filesystem boundaries
+--block-size=SIZE, -B force a fixed checksum block-size
+--rsh=COMMAND, -e specify the remote shell to use
+--rsync-path=PROGRAM specify the rsync to run on remote machine
+--existing skip creating new files on receiver
+--ignore-existing skip updating files that exist on receiver
+--remove-source-files sender removes synchronized files (non-dir)
+--del an alias for --delete-during
+--delete delete extraneous files from dest dirs
+--delete-before receiver deletes before xfer, not during
+--delete-during receiver deletes during the transfer
+--delete-delay find deletions during, delete after
+--delete-after receiver deletes after transfer, not during
+--delete-excluded also delete excluded files from dest dirs
+--ignore-missing-args ignore missing source args without error
+--delete-missing-args delete missing source args from destination
+--ignore-errors delete even if there are I/O errors
+--force force deletion of dirs even if not empty
+--max-delete=NUM don't delete more than NUM files
+--max-size=SIZE don't transfer any file larger than SIZE
+--min-size=SIZE don't transfer any file smaller than SIZE
+--max-alloc=SIZE change a limit relating to memory alloc
+--partial keep partially transferred files
+--partial-dir=DIR put a partially transferred file into DIR
+--delay-updates put all updated files into place at end
+--prune-empty-dirs, -m prune empty directory chains from file-list
+--numeric-ids don't map uid/gid values by user/group name
+--usermap=STRING custom username mapping
+--groupmap=STRING custom groupname mapping
+--chown=USER:GROUP simple username/groupname mapping
+--timeout=SECONDS set I/O timeout in seconds
+--contimeout=SECONDS set daemon connection timeout in seconds
+--ignore-times, -I don't skip files that match size and time
+--size-only skip files that match in size
+--modify-window=NUM, -@ set the accuracy for mod-time comparisons
+--temp-dir=DIR, -T create temporary files in directory DIR
+--fuzzy, -y find similar file for basis if no dest file
+--compare-dest=DIR also compare destination files relative to DIR
+--copy-dest=DIR ... and include copies of unchanged files
+--link-dest=DIR hardlink to files in DIR when unchanged
+--compress, -z compress file data during the transfer
+--compress-choice=STR choose the compression algorithm (aka --zc)
+--compress-level=NUM explicitly set compression level (aka --zl)
+--skip-compress=LIST skip compressing files with suffix in LIST
+--cvs-exclude, -C auto-ignore files in the same way CVS does
+--filter=RULE, -f add a file-filtering RULE
+-F same as --filter='dir-merge /.rsync-filter'
+ repeated: --filter='- .rsync-filter'
+--exclude=PATTERN exclude files matching PATTERN
+--exclude-from=FILE read exclude patterns from FILE
+--include=PATTERN don't exclude files matching PATTERN
+--include-from=FILE read include patterns from FILE
+--files-from=FILE read list of source-file names from FILE
+--from0, -0 all *-from/filter files are delimited by 0s
+--old-args disable the modern arg-protection idiom
+--secluded-args, -s use the protocol to safely send the args
+--trust-sender trust the remote sender's file list
+--copy-as=USER[:GROUP] specify user & optional group for the copy
+--address=ADDRESS bind address for outgoing socket to daemon
+--port=PORT specify double-colon alternate port number
+--sockopts=OPTIONS specify custom TCP options
+--blocking-io use blocking I/O for the remote shell
+--outbuf=N|L|B set out buffering to None, Line, or Block
+--stats give some file-transfer stats
+--8-bit-output, -8 leave high-bit chars unescaped in output
+--human-readable, -h output numbers in a human-readable format
+--progress show progress during transfer
+-P same as --partial --progress
+--itemize-changes, -i output a change-summary for all updates
+--remote-option=OPT, -M send OPTION to the remote side only
+--out-format=FORMAT output updates using the specified FORMAT
+--log-file=FILE log what we're doing to the specified FILE
+--log-file-format=FMT log updates using the specified FMT
+--password-file=FILE read daemon-access password from FILE
+--early-input=FILE use FILE for daemon's early exec input
+--list-only list the files instead of copying them
+--bwlimit=RATE limit socket I/O bandwidth
+--stop-after=MINS Stop rsync after MINS minutes have elapsed
+--stop-at=y-m-dTh:m Stop rsync at the specified point in time
+--fsync fsync every written file
+--write-batch=FILE write a batched update to FILE
+--only-write-batch=FILE like --write-batch but w/o updating dest
+--read-batch=FILE read a batched update from FILE
+--protocol=NUM force an older protocol version to be used
+--iconv=CONVERT_SPEC request charset conversion of filenames
+--checksum-seed=NUM set block/file checksum seed (advanced)
+--ipv4, -4 prefer IPv4
+--ipv6, -6 prefer IPv6
+--version, -V print the version + other info and exit
+--help, -h (*) show this help (* -h is help only on its own)
+.fi
+.P
+Rsync can also be run as a daemon, in which case the following options are
+accepted:
+.P
+.nf
+--daemon run as an rsync daemon
+--address=ADDRESS bind to the specified address
+--bwlimit=RATE limit socket I/O bandwidth
+--config=FILE specify alternate rsyncd.conf file
+--dparam=OVERRIDE, -M override global daemon config parameter
+--no-detach do not detach from the parent
+--port=PORT listen on alternate port number
+--log-file=FILE override the "log file" setting
+--log-file-format=FMT override the "log format" setting
+--sockopts=OPTIONS specify custom TCP options
+--verbose, -v increase verbosity
+--ipv4, -4 prefer IPv4
+--ipv6, -6 prefer IPv6
+--help, -h show this help (when used with --daemon)
+.fi
+.P
+.SH "OPTIONS"
+.P
+Rsync accepts both long (double-dash + word) and short (single-dash + letter)
+options. The full list of the available options are described below. If an
+option can be specified in more than one way, the choices are comma-separated.
+Some options only have a long variant, not a short.
+.P
+If the option takes a parameter, the parameter is only listed after the long
+variant, even though it must also be specified for the short. When specifying
+a parameter, you can either use the form \fB\-\-option=param\fP, \fB\-\-option\ param\fP,
+\fB\-o=param\fP, \fB\-o\ param\fP, or \fB\-oparam\fP (the latter choices assume that your
+option has a short variant).
+.P
+The parameter may need to be quoted in some manner for it to survive the
+shell's command-line parsing. Also keep in mind that a leading tilde (\fB~\fP) in
+a pathname is substituted by your shell, so make sure that you separate the
+option name from the pathname using a space if you want the local shell to
+expand it.
+.P
+.IP "\fB\-\-help\fP"
+Print a short help page describing the options available in rsync and exit.
+You can also use \fB\-h\fP for \fB\-\-help\fP when it is used without any other
+options (since it normally means \fB\-\-human-readable\fP).
+.IP "\fB\-\-version\fP, \fB\-V\fP"
+Print the rsync version plus other info and exit. When repeated, the
+information is output is a JSON format that is still fairly readable
+(client side only).
+.IP
+The output includes a list of compiled-in capabilities, a list of
+optimizations, the default list of checksum algorithms, the default list of
+compression algorithms, the default list of daemon auth digests, a link to
+the rsync web site, and a few other items.
+.IP "\fB\-\-verbose\fP, \fB\-v\fP"
+This option increases the amount of information you are given during the
+transfer. By default, rsync works silently. A single \fB\-v\fP will give you
+information about what files are being transferred and a brief summary at
+the end. Two \fB\-v\fP options will give you information on what files are
+being skipped and slightly more information at the end. More than two \fB\-v\fP
+options should only be used if you are debugging rsync.
+.IP
+The end-of-run summary tells you the number of bytes sent to the remote
+rsync (which is the receiving side on a local copy), the number of bytes
+received from the remote host, and the average bytes per second of the
+transferred data computed over the entire length of the rsync run. The
+second line shows the total size (in bytes), which is the sum of all the
+file sizes that rsync considered transferring. It also shows a "speedup"
+value, which is a ratio of the total file size divided by the sum of the
+sent and received bytes (which is really just a feel-good bigger-is-better
+number). Note that these byte values can be made more (or less)
+human-readable by using the \fB\-\-human-readable\fP (or
+\fB\-\-no-human-readable\fP) options.
+.IP
+In a modern rsync, the \fB\-v\fP option is equivalent to the setting of groups
+of \fB\-\-info\fP and \fB\-\-debug\fP options. You can choose to use
+these newer options in addition to, or in place of using \fB\-\-verbose\fP, as
+any fine-grained settings override the implied settings of \fB\-v\fP. Both
+\fB\-\-info\fP and \fB\-\-debug\fP have a way to ask for help that
+tells you exactly what flags are set for each increase in verbosity.
+.IP
+However, do keep in mind that a daemon's "\fBmax\ verbosity\fP" setting will limit
+how high of a level the various individual flags can be set on the daemon
+side. For instance, if the max is 2, then any info and/or debug flag that
+is set to a higher value than what would be set by \fB\-vv\fP will be downgraded
+to the \fB\-vv\fP level in the daemon's logging.
+.IP "\fB\-\-info=FLAGS\fP"
+This option lets you have fine-grained control over the information output
+you want to see. An individual flag name may be followed by a level
+number, with 0 meaning to silence that output, 1 being the default output
+level, and higher numbers increasing the output of that flag (for those
+that support higher levels). Use \fB\-\-info=help\fP to see all the available
+flag names, what they output, and what flag names are added for each
+increase in the verbose level. Some examples:
+.RS 4
+.IP
+.nf
+rsync -a --info=progress2 src/ dest/
+rsync -avv --info=stats2,misc1,flist0 src/ dest/
+.fi
+.RE
+.IP
+Note that \fB\-\-info=name\fP's output is affected by the \fB\-\-out-format\fP
+and \fB\-\-itemize-changes\fP (\fB\-i\fP) options. See those options for more
+information on what is output and when.
+.IP
+This option was added to 3.1.0, so an older rsync on the server side might
+reject your attempts at fine-grained control (if one or more flags needed
+to be send to the server and the server was too old to understand them).
+See also the "\fBmax\ verbosity\fP" caveat above when dealing with a daemon.
+.IP "\fB\-\-debug=FLAGS\fP"
+This option lets you have fine-grained control over the debug output you
+want to see. An individual flag name may be followed by a level number,
+with 0 meaning to silence that output, 1 being the default output level,
+and higher numbers increasing the output of that flag (for those that
+support higher levels). Use \fB\-\-debug=help\fP to see all the available flag
+names, what they output, and what flag names are added for each increase in
+the verbose level. Some examples:
+.RS 4
+.IP
+.nf
+rsync -avvv --debug=none src/ dest/
+rsync -avA --del --debug=del2,acl src/ dest/
+.fi
+.RE
+.IP
+Note that some debug messages will only be output when the \fB\-\-stderr=all\fP
+option is specified, especially those pertaining to I/O and buffer debugging.
+.IP
+Beginning in 3.2.0, this option is no longer auto-forwarded to the server
+side in order to allow you to specify different debug values for each side
+of the transfer, as well as to specify a new debug option that is only
+present in one of the rsync versions. If you want to duplicate the same
+option on both sides, using brace expansion is an easy way to save you some
+typing. This works in zsh and bash:
+.RS 4
+.IP
+.nf
+rsync -aiv {-M,}--debug=del2 src/ dest/
+.fi
+.RE
+.IP "\fB\-\-stderr=errors|all|client\fP"
+This option controls which processes output to stderr and if info messages
+are also changed to stderr. The mode strings can be abbreviated, so feel
+free to use a single letter value. The 3 possible choices are:
+.IP
+.RS
+.IP o
+\fBerrors\fP \- (the default) causes all the rsync processes to send an
+error directly to stderr, even if the process is on the remote side of
+the transfer. Info messages are sent to the client side via the protocol
+stream. If stderr is not available (i.e. when directly connecting with a
+daemon via a socket) errors fall back to being sent via the protocol
+stream.
+.IP o
+\fBall\fP \- causes all rsync messages (info and error) to get written
+directly to stderr from all (possible) processes. This causes stderr to
+become line-buffered (instead of raw) and eliminates the ability to
+divide up the info and error messages by file handle. For those doing
+debugging or using several levels of verbosity, this option can help to
+avoid clogging up the transfer stream (which should prevent any chance of
+a deadlock bug hanging things up). It also allows \fB\-\-debug\fP to
+enable some extra I/O related messages.
+.IP o
+\fBclient\fP \- causes all rsync messages to be sent to the client side
+via the protocol stream. One client process outputs all messages, with
+errors on stderr and info messages on stdout. This \fBwas\fP the default
+in older rsync versions, but can cause error delays when a lot of
+transfer data is ahead of the messages. If you're pushing files to an
+older rsync, you may want to use \fB\-\-stderr=all\fP since that idiom has
+been around for several releases.
+.RE
+.IP
+This option was added in rsync 3.2.3. This version also began the
+forwarding of a non-default setting to the remote side, though rsync uses
+the backward-compatible options \fB\-\-msgs2stderr\fP and \fB\-\-no-msgs2stderr\fP to
+represent the \fBall\fP and \fBclient\fP settings, respectively. A newer rsync
+will continue to accept these older option names to maintain compatibility.
+.IP "\fB\-\-quiet\fP, \fB\-q\fP"
+This option decreases the amount of information you are given during the
+transfer, notably suppressing information messages from the remote server.
+This option is useful when invoking rsync from cron.
+.IP "\fB\-\-no-motd\fP"
+This option affects the information that is output by the client at the
+start of a daemon transfer. This suppresses the message-of-the-day (MOTD)
+text, but it also affects the list of modules that the daemon sends in
+response to the "rsync host::" request (due to a limitation in the rsync
+protocol), so omit this option if you want to request the list of modules
+from the daemon.
+.IP "\fB\-\-ignore-times\fP, \fB\-I\fP"
+Normally rsync will skip any files that are already the same size and have
+the same modification timestamp. This option turns off this "quick check"
+behavior, causing all files to be updated.
+.IP
+This option can be confusing compared to \fB\-\-ignore-existing\fP and
+\fB\-\-ignore-non-existing\fP in that that they cause rsync to transfer
+fewer files, while this option causes rsync to transfer more files.
+.IP "\fB\-\-size-only\fP"
+This modifies rsync's "quick check" algorithm for finding files that need
+to be transferred, changing it from the default of transferring files with
+either a changed size or a changed last-modified time to just looking for
+files that have changed in size. This is useful when starting to use rsync
+after using another mirroring system which may not preserve timestamps
+exactly.
+.IP "\fB\-\-modify-window=NUM\fP, \fB\-@\fP"
+When comparing two timestamps, rsync treats the timestamps as being equal
+if they differ by no more than the modify-window value. The default is 0,
+which matches just integer seconds. If you specify a negative value (and
+the receiver is at least version 3.1.3) then nanoseconds will also be taken
+into account. Specifying 1 is useful for copies to/from MS Windows FAT
+filesystems, because FAT represents times with a 2-second resolution
+(allowing times to differ from the original by up to 1 second).
+.IP
+If you want all your transfers to default to comparing nanoseconds, you can
+create a \fB~/.popt\fP file and put these lines in it:
+.RS 4
+.IP
+.nf
+rsync alias -a -a@-1
+rsync alias -t -t@-1
+.fi
+.RE
+.IP
+With that as the default, you'd need to specify \fB\-\-modify-window=0\fP (aka
+\fB\-@0\fP) to override it and ignore nanoseconds, e.g. if you're copying
+between ext3 and ext4, or if the receiving rsync is older than 3.1.3.
+.IP "\fB\-\-checksum\fP, \fB\-c\fP"
+This changes the way rsync checks if the files have been changed and are in
+need of a transfer. Without this option, rsync uses a "quick check" that
+(by default) checks if each file's size and time of last modification match
+between the sender and receiver. This option changes this to compare a
+128-bit checksum for each file that has a matching size. Generating the
+checksums means that both sides will expend a lot of disk I/O reading all
+the data in the files in the transfer, so this can slow things down
+significantly (and this is prior to any reading that will be done to
+transfer changed files)
+.IP
+The sending side generates its checksums while it is doing the file-system
+scan that builds the list of the available files. The receiver generates
+its checksums when it is scanning for changed files, and will checksum any
+file that has the same size as the corresponding sender's file: files with
+either a changed size or a changed checksum are selected for transfer.
+.IP
+Note that rsync always verifies that each \fItransferred\fP file was correctly
+reconstructed on the receiving side by checking a whole-file checksum that
+is generated as the file is transferred, but that automatic
+after-the-transfer verification has nothing to do with this option's
+before-the-transfer "Does this file need to be updated?" check.
+.IP
+The checksum used is auto-negotiated between the client and the server, but
+can be overridden using either the \fB\-\-checksum-choice\fP (\fB\-\-cc\fP)
+option or an environment variable that is discussed in that option's
+section.
+.IP "\fB\-\-archive\fP, \fB\-a\fP"
+This is equivalent to \fB\-rlptgoD\fP. It is a quick way of saying you want
+recursion and want to preserve almost everything. Be aware that it does
+\fBnot\fP include preserving ACLs (\fB\-A\fP), xattrs (\fB\-X\fP), atimes (\fB\-U\fP),
+crtimes (\fB\-N\fP), nor the finding and preserving of hardlinks (\fB\-H\fP).
+.IP
+The only exception to the above equivalence is when \fB\-\-files-from\fP
+is specified, in which case \fB\-r\fP is not implied.
+.IP "\fB\-\-no-OPTION\fP"
+You may turn off one or more implied options by prefixing the option name
+with "no-". Not all positive options have a negated opposite, but a lot
+do, including those that can be used to disable an implied option (e.g.
+\fB\-\-no-D\fP, \fB\-\-no-perms\fP) or have different defaults in various circumstances
+(e.g. \fB\-\-no-whole-file\fP, \fB\-\-no-blocking-io\fP, \fB\-\-no-dirs\fP). Every
+valid negated option accepts both the short and the long option name after
+the "no-" prefix (e.g. \fB\-\-no-R\fP is the same as \fB\-\-no-relative\fP).
+.IP
+As an example, if you want to use \fB\-\-archive\fP (\fB\-a\fP) but don't want
+\fB\-\-owner\fP (\fB\-o\fP), instead of converting \fB\-a\fP into \fB\-rlptgD\fP, you
+can specify \fB\-a\ \-\-no-o\fP (aka \fB\-\-archive\ \-\-no-owner\fP).
+.IP
+The order of the options is important: if you specify \fB\-\-no-r\ \-a\fP, the \fB\-r\fP
+option would end up being turned on, the opposite of \fB\-a\ \-\-no-r\fP. Note
+also that the side-effects of the \fB\-\-files-from\fP option are NOT
+positional, as it affects the default state of several options and slightly
+changes the meaning of \fB\-a\fP (see the \fB\-\-files-from\fP option
+for more details).
+.IP "\fB\-\-recursive\fP, \fB\-r\fP"
+This tells rsync to copy directories recursively. See also
+\fB\-\-dirs\fP (\fB\-d\fP) for an option that allows the scanning of a single
+directory.
+.IP
+See the \fB\-\-inc-recursive\fP option for a discussion of the
+incremental recursion for creating the list of files to transfer.
+.IP "\fB\-\-inc-recursive\fP, \fB\-\-i-r\fP"
+This option explicitly enables on incremental recursion when scanning for
+files, which is enabled by default when using the \fB\-\-recursive\fP
+option and both sides of the transfer are running rsync 3.0.0 or newer.
+.IP
+Incremental recursion uses much less memory than non-incremental, while
+also beginning the transfer more quickly (since it doesn't need to scan the
+entire transfer hierarchy before it starts transferring files). If no
+recursion is enabled in the source files, this option has no effect.
+.IP
+Some options require rsync to know the full file list, so these options
+disable the incremental recursion mode. These include:
+.IP
+.RS
+.IP o
+\fB\-\-delete-before\fP (the old default of \fB\-\-delete\fP)
+.IP o
+\fB\-\-delete-after\fP
+.IP o
+\fB\-\-prune-empty-dirs\fP
+.IP o
+\fB\-\-delay-updates\fP
+.RE
+.IP
+In order to make \fB\-\-delete\fP compatible with incremental recursion,
+rsync 3.0.0 made \fB\-\-delete-during\fP the default delete mode (which
+was first added in 2.6.4).
+.IP
+One side-effect of incremental recursion is that any missing
+sub-directories inside a recursively-scanned directory are (by default)
+created prior to recursing into the sub-dirs. This earlier creation point
+(compared to a non-incremental recursion) allows rsync to then set the
+modify time of the finished directory right away (without having to delay
+that until a bunch of recursive copying has finished). However, these
+early directories don't yet have their completed mode, mtime, or ownership
+set\ \-\- they have more restrictive rights until the subdirectory's copying
+actually begins. This early-creation idiom can be avoided by using the
+\fB\-\-omit-dir-times\fP option.
+.IP
+Incremental recursion can be disabled using the
+\fB\-\-no-inc-recursive\fP (\fB\-\-no-i-r\fP) option.
+.IP "\fB\-\-no-inc-recursive\fP, \fB\-\-no-i-r\fP"
+Disables the new incremental recursion algorithm of the
+\fB\-\-recursive\fP option. This makes rsync scan the full file list
+before it begins to transfer files. See \fB\-\-inc-recursive\fP for more
+info.
+.IP "\fB\-\-relative\fP, \fB\-R\fP"
+Use relative paths. This means that the full path names specified on the
+command line are sent to the server rather than just the last parts of the
+filenames. This is particularly useful when you want to send several
+different directories at the same time. For example, if you used this
+command:
+.RS 4
+.IP
+.nf
+rsync -av /foo/bar/baz.c remote:/tmp/
+.fi
+.RE
+.IP
+would create a file named baz.c in /tmp/ on the remote machine. If instead
+you used
+.RS 4
+.IP
+.nf
+rsync -avR /foo/bar/baz.c remote:/tmp/
+.fi
+.RE
+.IP
+then a file named /tmp/foo/bar/baz.c would be created on the remote
+machine, preserving its full path. These extra path elements are called
+"implied directories" (i.e. the "foo" and the "foo/bar" directories in the
+above example).
+.IP
+Beginning with rsync 3.0.0, rsync always sends these implied directories as
+real directories in the file list, even if a path element is really a
+symlink on the sending side. This prevents some really unexpected behaviors
+when copying the full path of a file that you didn't realize had a symlink
+in its path. If you want to duplicate a server-side symlink, include both
+the symlink via its path, and referent directory via its real path. If
+you're dealing with an older rsync on the sending side, you may need to use
+the \fB\-\-no-implied-dirs\fP option.
+.IP
+It is also possible to limit the amount of path information that is sent as
+implied directories for each path you specify. With a modern rsync on the
+sending side (beginning with 2.6.7), you can insert a dot and a slash into
+the source path, like this:
+.RS 4
+.IP
+.nf
+rsync -avR /foo/./bar/baz.c remote:/tmp/
+.fi
+.RE
+.IP
+That would create /tmp/bar/baz.c on the remote machine. (Note that the dot
+must be followed by a slash, so "/foo/." would not be abbreviated.) For
+older rsync versions, you would need to use a chdir to limit the source
+path. For example, when pushing files:
+.RS 4
+.IP
+.nf
+(cd /foo; rsync -avR bar/baz.c remote:/tmp/)
+.fi
+.RE
+.IP
+(Note that the parens put the two commands into a sub-shell, so that the
+"cd" command doesn't remain in effect for future commands.) If you're
+pulling files from an older rsync, use this idiom (but only for a
+non-daemon transfer):
+.RS 4
+.IP
+.nf
+rsync -avR --rsync-path="cd /foo; rsync" \\
+ remote:bar/baz.c /tmp/
+.fi
+.RE
+.IP "\fB\-\-no-implied-dirs\fP"
+This option affects the default behavior of the \fB\-\-relative\fP option. When
+it is specified, the attributes of the implied directories from the source
+names are not included in the transfer. This means that the corresponding
+path elements on the destination system are left unchanged if they exist,
+and any missing implied directories are created with default attributes.
+This even allows these implied path elements to have big differences, such
+as being a symlink to a directory on the receiving side.
+.IP
+For instance, if a command-line arg or a files-from entry told rsync to
+transfer the file "path/foo/file", the directories "path" and "path/foo"
+are implied when \fB\-\-relative\fP is used. If "path/foo" is a symlink to "bar"
+on the destination system, the receiving rsync would ordinarily delete
+"path/foo", recreate it as a directory, and receive the file into the new
+directory. With \fB\-\-no-implied-dirs\fP, the receiving rsync updates
+"path/foo/file" using the existing path elements, which means that the file
+ends up being created in "path/bar". Another way to accomplish this link
+preservation is to use the \fB\-\-keep-dirlinks\fP option (which will also affect
+symlinks to directories in the rest of the transfer).
+.IP
+When pulling files from an rsync older than 3.0.0, you may need to use this
+option if the sending side has a symlink in the path you request and you
+wish the implied directories to be transferred as normal directories.
+.IP "\fB\-\-backup\fP, \fB\-b\fP"
+With this option, preexisting destination files are renamed as each file is
+transferred or deleted. You can control where the backup file goes and
+what (if any) suffix gets appended using the \fB\-\-backup-dir\fP and
+\fB\-\-suffix\fP options.
+.IP
+If you don't specify \fB\-\-backup-dir\fP:
+.RS
+.IP
+.IP 1.
+the \fB\-\-omit-dir-times\fP option will be forced on
+.IP 2.
+the use of \fB\-\-delete\fP (without \fB\-\-delete-excluded\fP),
+causes rsync to add a "protect" filter-rule for the
+backup suffix to the end of all your existing filters that looks like
+this: \fB\-f\ "P\ *~"\fP. This rule prevents previously backed-up files from
+being deleted.
+.RE
+.IP
+Note that if you are supplying your own filter rules, you may need to
+manually insert your own exclude/protect rule somewhere higher up in the
+list so that it has a high enough priority to be effective (e.g. if your
+rules specify a trailing inclusion/exclusion of \fB*\fP, the auto-added rule
+would never be reached).
+.IP "\fB\-\-backup-dir=DIR\fP"
+This implies the \fB\-\-backup\fP option, and tells rsync to store all
+backups in the specified directory on the receiving side. This can be used
+for incremental backups. You can additionally specify a backup suffix
+using the \fB\-\-suffix\fP option (otherwise the files backed up in the
+specified directory will keep their original filenames).
+.IP
+Note that if you specify a relative path, the backup directory will be
+relative to the destination directory, so you probably want to specify
+either an absolute path or a path that starts with "../". If an rsync
+daemon is the receiver, the backup dir cannot go outside the module's path
+hierarchy, so take extra care not to delete it or copy into it.
+.IP "\fB\-\-suffix=SUFFIX\fP"
+This option allows you to override the default backup suffix used with the
+\fB\-\-backup\fP (\fB\-b\fP) option. The default suffix is a \fB~\fP if no
+\fB\-\-backup-dir\fP was specified, otherwise it is an empty string.
+.IP "\fB\-\-update\fP, \fB\-u\fP"
+This forces rsync to skip any files which exist on the destination and have
+a modified time that is newer than the source file. (If an existing
+destination file has a modification time equal to the source file's, it
+will be updated if the sizes are different.)
+.IP
+Note that this does not affect the copying of dirs, symlinks, or other
+special files. Also, a difference of file format between the sender and
+receiver is always considered to be important enough for an update, no
+matter what date is on the objects. In other words, if the source has a
+directory where the destination has a file, the transfer would occur
+regardless of the timestamps.
+.IP
+This option is a TRANSFER RULE, so don't expect any
+exclude side effects.
+.IP
+A caution for those that choose to combine \fB\-\-inplace\fP with
+\fB\-\-update\fP: an interrupted transfer will leave behind a partial file on the
+receiving side that has a very recent modified time, so re-running the
+transfer will probably \fBnot\fP continue the interrupted file. As such, it
+is usually best to avoid combining this with \fB\-\-inplace\fP unless you
+have implemented manual steps to handle any interrupted in-progress files.
+.IP "\fB\-\-inplace\fP"
+This option changes how rsync transfers a file when its data needs to be
+updated: instead of the default method of creating a new copy of the file
+and moving it into place when it is complete, rsync instead writes the
+updated data directly to the destination file.
+.IP
+This has several effects:
+.IP
+.RS
+.IP o
+Hard links are not broken. This means the new data will be visible
+through other hard links to the destination file. Moreover, attempts to
+copy differing source files onto a multiply-linked destination file will
+result in a "tug of war" with the destination data changing back and
+forth.
+.IP o
+In-use binaries cannot be updated (either the OS will prevent this from
+happening, or binaries that attempt to swap-in their data will misbehave
+or crash).
+.IP o
+The file's data will be in an inconsistent state during the transfer and
+will be left that way if the transfer is interrupted or if an update
+fails.
+.IP o
+A file that rsync cannot write to cannot be updated. While a super user
+can update any file, a normal user needs to be granted write permission
+for the open of the file for writing to be successful.
+.IP o
+The efficiency of rsync's delta-transfer algorithm may be reduced if some
+data in the destination file is overwritten before it can be copied to a
+position later in the file. This does not apply if you use \fB\-\-backup\fP,
+since rsync is smart enough to use the backup file as the basis file for
+the transfer.
+.RE
+.IP
+WARNING: you should not use this option to update files that are being
+accessed by others, so be careful when choosing to use this for a copy.
+.IP
+This option is useful for transferring large files with block-based changes
+or appended data, and also on systems that are disk bound, not network
+bound. It can also help keep a copy-on-write filesystem snapshot from
+diverging the entire contents of a file that only has minor changes.
+.IP
+The option implies \fB\-\-partial\fP (since an interrupted transfer does
+not delete the file), but conflicts with \fB\-\-partial-dir\fP and
+\fB\-\-delay-updates\fP. Prior to rsync 2.6.4 \fB\-\-inplace\fP was also
+incompatible with \fB\-\-compare-dest\fP and \fB\-\-link-dest\fP.
+.IP "\fB\-\-append\fP"
+This special copy mode only works to efficiently update files that are
+known to be growing larger where any existing content on the receiving side
+is also known to be the same as the content on the sender. The use of
+\fB\-\-append\fP \fBcan be dangerous\fP if you aren't 100% sure that all the files
+in the transfer are shared, growing files. You should thus use filter
+rules to ensure that you weed out any files that do not fit this criteria.
+.IP
+Rsync updates these growing file in-place without verifying any of the
+existing content in the file (it only verifies the content that it is
+appending). Rsync skips any files that exist on the receiving side that
+are not shorter than the associated file on the sending side (which means
+that new files are transferred). It also skips any files whose size on the
+sending side gets shorter during the send negotiations (rsync warns about a
+"diminished" file when this happens).
+.IP
+This does not interfere with the updating of a file's non-content
+attributes (e.g. permissions, ownership, etc.) when the file does not need
+to be transferred, nor does it affect the updating of any directories or
+non-regular files.
+.IP "\fB\-\-append-verify\fP"
+This special copy mode works like \fB\-\-append\fP except that all the
+data in the file is included in the checksum verification (making it less
+efficient but also potentially safer). This option \fBcan be dangerous\fP if
+you aren't 100% sure that all the files in the transfer are shared, growing
+files. See the \fB\-\-append\fP option for more details.
+.IP
+Note: prior to rsync 3.0.0, the \fB\-\-append\fP option worked like
+\fB\-\-append-verify\fP, so if you are interacting with an older rsync (or the
+transfer is using a protocol prior to 30), specifying either append option
+will initiate an \fB\-\-append-verify\fP transfer.
+.IP "\fB\-\-dirs\fP, \fB\-d\fP"
+Tell the sending side to include any directories that are encountered.
+Unlike \fB\-\-recursive\fP, a directory's contents are not copied unless
+the directory name specified is "." or ends with a trailing slash (e.g.
+".", "dir/.", "dir/", etc.). Without this option or the
+\fB\-\-recursive\fP option, rsync will skip all directories it encounters
+(and output a message to that effect for each one). If you specify both
+\fB\-\-dirs\fP and \fB\-\-recursive\fP, \fB\-\-recursive\fP takes precedence.
+.IP
+The \fB\-\-dirs\fP option is implied by the \fB\-\-files-from\fP option or the
+\fB\-\-list-only\fP option (including an implied \fB\-\-list-only\fP
+usage) if \fB\-\-recursive\fP wasn't specified (so that directories are
+seen in the listing). Specify \fB\-\-no-dirs\fP (or \fB\-\-no-d\fP) if you want to
+turn this off.
+.IP
+There is also a backward-compatibility helper option, \fB\-\-old-dirs\fP
+(\fB\-\-old-d\fP) that tells rsync to use a hack of \fB\-r\ \-\-exclude='/*/*'\fP to get
+an older rsync to list a single directory without recursing.
+.IP "\fB\-\-mkpath\fP"
+Create all missing path components of the destination path.
+.IP
+By default, rsync allows only the final component of the destination path
+to not exist, which is an attempt to help you to validate your destination
+path. With this option, rsync creates all the missing destination-path
+components, just as if \fBmkdir\ \-p\ $DEST_PATH\fP had been run on the receiving
+side.
+.IP
+When specifying a destination path, including a trailing slash ensures that
+the whole path is treated as directory names to be created, even when the
+file list has a single item. See the COPYING TO A DIFFERENT NAME
+section for full details on how rsync decides if a final destination-path
+component should be created as a directory or not.
+.IP
+If you would like the newly-created destination dirs to match the dirs on
+the sending side, you should be using \fB\-\-relative\fP (\fB\-R\fP) instead
+of \fB\-\-mkpath\fP. For instance, the following two commands result in the same
+destination tree, but only the second command ensures that the
+"some/extra/path" components match the dirs on the sending side:
+.RS 4
+.IP
+.nf
+rsync -ai --mkpath host:some/extra/path/*.c some/extra/path/
+rsync -aiR host:some/extra/path/*.c ./
+.fi
+.RE
+.IP "\fB\-\-links\fP, \fB\-l\fP"
+Add symlinks to the transferred files instead of noisily ignoring them with
+a "non-regular file" warning for each symlink encountered. You can
+alternately silence the warning by specifying \fB\-\-info=nonreg0\fP.
+.IP
+The default handling of symlinks is to recreate each symlink's unchanged
+value on the receiving side.
+.IP
+See the SYMBOLIC LINKS section for multi-option info.
+.IP "\fB\-\-copy-links\fP, \fB\-L\fP"
+The sender transforms each symlink encountered in the transfer into the
+referent item, following the symlink chain to the file or directory that it
+references. If a symlink chain is broken, an error is output and the file
+is dropped from the transfer.
+.IP
+This option supersedes any other options that affect symlinks in the
+transfer, since there are no symlinks left in the transfer.
+.IP
+This option does not change the handling of existing symlinks on the
+receiving side, unlike versions of rsync prior to 2.6.3 which had the
+side-effect of telling the receiving side to also follow symlinks. A
+modern rsync won't forward this option to a remote receiver (since only the
+sender needs to know about it), so this caveat should only affect someone
+using an rsync client older than 2.6.7 (which is when \fB\-L\fP stopped being
+forwarded to the receiver).
+.IP
+See the \fB\-\-keep-dirlinks\fP (\fB\-K\fP) if you need a symlink to a
+directory to be treated as a real directory on the receiving side.
+.IP
+See the SYMBOLIC LINKS section for multi-option info.
+.IP "\fB\-\-copy-unsafe-links\fP"
+This tells rsync to copy the referent of symbolic links that point outside
+the copied tree. Absolute symlinks are also treated like ordinary files,
+and so are any symlinks in the source path itself when \fB\-\-relative\fP
+is used.
+.IP
+Note that the cut-off point is the top of the transfer, which is the part
+of the path that rsync isn't mentioning in the verbose output. If you copy
+"/src/subdir" to "/dest/" then the "subdir" directory is a name inside the
+transfer tree, not the top of the transfer (which is /src) so it is legal
+for created relative symlinks to refer to other names inside the /src and
+/dest directories. If you instead copy "/src/subdir/" (with a trailing
+slash) to "/dest/subdir" that would not allow symlinks to any files outside
+of "subdir".
+.IP
+Note that safe symlinks are only copied if \fB\-\-links\fP was also
+specified or implied. The \fB\-\-copy-unsafe-links\fP option has no extra effect
+when combined with \fB\-\-copy-links\fP.
+.IP
+See the SYMBOLIC LINKS section for multi-option info.
+.IP "\fB\-\-safe-links\fP"
+This tells the receiving rsync to ignore any symbolic links in the transfer
+which point outside the copied tree. All absolute symlinks are also
+ignored.
+.IP
+Since this ignoring is happening on the receiving side, it will still be
+effective even when the sending side has munged symlinks (when it is using
+\fB\-\-munge-links\fP). It also affects deletions, since the file being
+present in the transfer prevents any matching file on the receiver from
+being deleted when the symlink is deemed to be unsafe and is skipped.
+.IP
+This option must be combined with \fB\-\-links\fP (or
+\fB\-\-archive\fP) to have any symlinks in the transfer to conditionally
+ignore. Its effect is superseded by \fB\-\-copy-unsafe-links\fP.
+.IP
+Using this option in conjunction with \fB\-\-relative\fP may give
+unexpected results.
+.IP
+See the SYMBOLIC LINKS section for multi-option info.
+.IP "\fB\-\-munge-links\fP"
+This option affects just one side of the transfer and tells rsync to munge
+symlink values when it is receiving files or unmunge symlink values when it
+is sending files. The munged values make the symlinks unusable on disk but
+allows the original contents of the symlinks to be recovered.
+.IP
+The server-side rsync often enables this option without the client's
+knowledge, such as in an rsync daemon's configuration file or by an option
+given to the rrsync (restricted rsync) script. When specified on the
+client side, specify the option normally if it is the client side that
+has/needs the munged symlinks, or use \fB\-M\-\-munge-links\fP to give the option
+to the server when it has/needs the munged symlinks. Note that on a local
+transfer, the client is the sender, so specifying the option directly
+unmunges symlinks while specifying it as a remote option munges symlinks.
+.IP
+This option has no effect when sent to a daemon via \fB\-\-remote-option\fP
+because the daemon configures whether it wants munged symlinks via its
+"\fBmunge\ symlinks\fP" parameter.
+.IP
+The symlink value is munged/unmunged once it is in the transfer, so any
+option that transforms symlinks into non-symlinks occurs prior to the
+munging/unmunging \fBexcept\fP for \fB\-\-safe-links\fP, which is a choice
+that the receiver makes, so it bases its decision on the munged/unmunged
+value. This does mean that if a receiver has munging enabled, that using
+\fB\-\-safe-links\fP will cause all symlinks to be ignored (since they
+are all absolute).
+.IP
+The method that rsync uses to munge the symlinks is to prefix each one's
+value with the string "/rsyncd-munged/". This prevents the links from
+being used as long as the directory does not exist. When this option is
+enabled, rsync will refuse to run if that path is a directory or a symlink
+to a directory (though it only checks at startup). See also the
+"munge-symlinks" python script in the support directory of the source code
+for a way to munge/unmunge one or more symlinks in-place.
+.IP "\fB\-\-copy-dirlinks\fP, \fB\-k\fP"
+This option causes the sending side to treat a symlink to a directory as
+though it were a real directory. This is useful if you don't want symlinks
+to non-directories to be affected, as they would be using
+\fB\-\-copy-links\fP.
+.IP
+Without this option, if the sending side has replaced a directory with a
+symlink to a directory, the receiving side will delete anything that is in
+the way of the new symlink, including a directory hierarchy (as long as
+\fB\-\-force\fP or \fB\-\-delete\fP is in effect).
+.IP
+See also \fB\-\-keep-dirlinks\fP for an analogous option for the
+receiving side.
+.IP
+\fB\-\-copy-dirlinks\fP applies to all symlinks to directories in the source. If
+you want to follow only a few specified symlinks, a trick you can use is to
+pass them as additional source args with a trailing slash, using
+\fB\-\-relative\fP to make the paths match up right. For example:
+.RS 4
+.IP
+.nf
+rsync -r --relative src/./ src/./follow-me/ dest/
+.fi
+.RE
+.IP
+This works because rsync calls \fBlstat\fP(2) on the source arg as given, and
+the trailing slash makes \fBlstat\fP(2) follow the symlink, giving rise to a
+directory in the file-list which overrides the symlink found during the
+scan of "src/./".
+.IP
+See the SYMBOLIC LINKS section for multi-option info.
+.IP "\fB\-\-keep-dirlinks\fP, \fB\-K\fP"
+This option causes the receiving side to treat a symlink to a directory as
+though it were a real directory, but only if it matches a real directory
+from the sender. Without this option, the receiver's symlink would be
+deleted and replaced with a real directory.
+.IP
+For example, suppose you transfer a directory "foo" that contains a file
+"file", but "foo" is a symlink to directory "bar" on the receiver. Without
+\fB\-\-keep-dirlinks\fP, the receiver deletes symlink "foo", recreates it as a
+directory, and receives the file into the new directory. With
+\fB\-\-keep-dirlinks\fP, the receiver keeps the symlink and "file" ends up in
+"bar".
+.IP
+One note of caution: if you use \fB\-\-keep-dirlinks\fP, you must trust all the
+symlinks in the copy or enable the \fB\-\-munge-links\fP option on the
+receiving side! If it is possible for an untrusted user to create their
+own symlink to any real directory, the user could then (on a subsequent
+copy) replace the symlink with a real directory and affect the content of
+whatever directory the symlink references. For backup copies, you are
+better off using something like a bind mount instead of a symlink to modify
+your receiving hierarchy.
+.IP
+See also \fB\-\-copy-dirlinks\fP for an analogous option for the sending
+side.
+.IP
+See the SYMBOLIC LINKS section for multi-option info.
+.IP "\fB\-\-hard-links\fP, \fB\-H\fP"
+This tells rsync to look for hard-linked files in the source and link
+together the corresponding files on the destination. Without this option,
+hard-linked files in the source are treated as though they were separate
+files.
+.IP
+This option does NOT necessarily ensure that the pattern of hard links on
+the destination exactly matches that on the source. Cases in which the
+destination may end up with extra hard links include the following:
+.IP
+.RS
+.IP o
+If the destination contains extraneous hard-links (more linking than what
+is present in the source file list), the copying algorithm will not break
+them explicitly. However, if one or more of the paths have content
+differences, the normal file-update process will break those extra links
+(unless you are using the \fB\-\-inplace\fP option).
+.IP o
+If you specify a \fB\-\-link-dest\fP directory that contains hard
+links, the linking of the destination files against the
+\fB\-\-link-dest\fP files can cause some paths in the destination to
+become linked together due to the \fB\-\-link-dest\fP associations.
+.RE
+.IP
+Note that rsync can only detect hard links between files that are inside
+the transfer set. If rsync updates a file that has extra hard-link
+connections to files outside the transfer, that linkage will be broken. If
+you are tempted to use the \fB\-\-inplace\fP option to avoid this breakage, be
+very careful that you know how your files are being updated so that you are
+certain that no unintended changes happen due to lingering hard links (and
+see the \fB\-\-inplace\fP option for more caveats).
+.IP
+If incremental recursion is active (see \fB\-\-inc-recursive\fP), rsync
+may transfer a missing hard-linked file before it finds that another link
+for that contents exists elsewhere in the hierarchy. This does not affect
+the accuracy of the transfer (i.e. which files are hard-linked together),
+just its efficiency (i.e. copying the data for a new, early copy of a
+hard-linked file that could have been found later in the transfer in
+another member of the hard-linked set of files). One way to avoid this
+inefficiency is to disable incremental recursion using the
+\fB\-\-no-inc-recursive\fP option.
+.IP "\fB\-\-perms\fP, \fB\-p\fP"
+This option causes the receiving rsync to set the destination permissions
+to be the same as the source permissions. (See also the \fB\-\-chmod\fP
+option for a way to modify what rsync considers to be the source
+permissions.)
+.IP
+When this option is \fIoff\fP, permissions are set as follows:
+.IP
+.RS
+.IP o
+Existing files (including updated files) retain their existing
+permissions, though the \fB\-\-executability\fP option might change
+just the execute permission for the file.
+.IP o
+New files get their "normal" permission bits set to the source file's
+permissions masked with the receiving directory's default permissions
+(either the receiving process's umask, or the permissions specified via
+the destination directory's default ACL), and their special permission
+bits disabled except in the case where a new directory inherits a setgid
+bit from its parent directory.
+.RE
+.IP
+Thus, when \fB\-\-perms\fP and \fB\-\-executability\fP are both disabled, rsync's
+behavior is the same as that of other file-copy utilities, such as \fBcp\fP(1)
+and \fBtar\fP(1).
+.IP
+In summary: to give destination files (both old and new) the source
+permissions, use \fB\-\-perms\fP. To give new files the destination-default
+permissions (while leaving existing files unchanged), make sure that the
+\fB\-\-perms\fP option is off and use \fB\-\-chmod=ugo=rwX\fP (which ensures
+that all non-masked bits get enabled). If you'd care to make this latter
+behavior easier to type, you could define a popt alias for it, such as
+putting this line in the file \fB~/.popt\fP (the following defines the \fB\-Z\fP
+option, and includes \fB\-\-no-g\fP to use the default group of the destination
+dir):
+.RS 4
+.IP
+.nf
+rsync alias -Z --no-p --no-g --chmod=ugo=rwX
+.fi
+.RE
+.IP
+You could then use this new option in a command such as this one:
+.RS 4
+.IP
+.nf
+rsync -avZ src/ dest/
+.fi
+.RE
+.IP
+(Caveat: make sure that \fB\-a\fP does not follow \fB\-Z\fP, or it will re-enable the
+two \fB\-\-no-*\fP options mentioned above.)
+.IP
+The preservation of the destination's setgid bit on newly-created
+directories when \fB\-\-perms\fP is off was added in rsync 2.6.7. Older rsync
+versions erroneously preserved the three special permission bits for
+newly-created files when \fB\-\-perms\fP was off, while overriding the
+destination's setgid bit setting on a newly-created directory. Default ACL
+observance was added to the ACL patch for rsync 2.6.7, so older (or
+non-ACL-enabled) rsyncs use the umask even if default ACLs are present.
+(Keep in mind that it is the version of the receiving rsync that affects
+these behaviors.)
+.IP "\fB\-\-executability\fP, \fB\-E\fP"
+This option causes rsync to preserve the executability (or
+non-executability) of regular files when \fB\-\-perms\fP is not enabled.
+A regular file is considered to be executable if at least one 'x' is turned
+on in its permissions. When an existing destination file's executability
+differs from that of the corresponding source file, rsync modifies the
+destination file's permissions as follows:
+.IP
+.RS
+.IP o
+To make a file non-executable, rsync turns off all its 'x' permissions.
+.IP o
+To make a file executable, rsync turns on each 'x' permission that has a
+corresponding 'r' permission enabled.
+.RE
+.IP
+If \fB\-\-perms\fP is enabled, this option is ignored.
+.IP "\fB\-\-acls\fP, \fB\-A\fP"
+This option causes rsync to update the destination ACLs to be the same as
+the source ACLs. The option also implies \fB\-\-perms\fP.
+.IP
+The source and destination systems must have compatible ACL entries for
+this option to work properly. See the \fB\-\-fake-super\fP option for a
+way to backup and restore ACLs that are not compatible.
+.IP "\fB\-\-xattrs\fP, \fB\-X\fP"
+This option causes rsync to update the destination extended attributes to
+be the same as the source ones.
+.IP
+For systems that support extended-attribute namespaces, a copy being done
+by a super-user copies all namespaces except system.*. A normal user only
+copies the user.* namespace. To be able to backup and restore non-user
+namespaces as a normal user, see the \fB\-\-fake-super\fP option.
+.IP
+The above name filtering can be overridden by using one or more filter
+options with the \fBx\fP modifier. When you specify an xattr-affecting
+filter rule, rsync requires that you do your own system/user filtering, as
+well as any additional filtering for what xattr names are copied and what
+names are allowed to be deleted. For example, to skip the system
+namespace, you could specify:
+.RS 4
+.IP
+.nf
+--filter='-x system.*'
+.fi
+.RE
+.IP
+To skip all namespaces except the user namespace, you could specify a
+negated-user match:
+.RS 4
+.IP
+.nf
+--filter='-x! user.*'
+.fi
+.RE
+.IP
+To prevent any attributes from being deleted, you could specify a
+receiver-only rule that excludes all names:
+.RS 4
+.IP
+.nf
+--filter='-xr *'
+.fi
+.RE
+.IP
+Note that the \fB\-X\fP option does not copy rsync's special xattr values (e.g.
+those used by \fB\-\-fake-super\fP) unless you repeat the option (e.g. \fB\-XX\fP).
+This "copy all xattrs" mode cannot be used with \fB\-\-fake-super\fP.
+.IP "\fB\-\-chmod=CHMOD\fP"
+This option tells rsync to apply one or more comma-separated "chmod" modes
+to the permission of the files in the transfer. The resulting value is
+treated as though it were the permissions that the sending side supplied
+for the file, which means that this option can seem to have no effect on
+existing files if \fB\-\-perms\fP is not enabled.
+.IP
+In addition to the normal parsing rules specified in the \fBchmod\fP(1)
+manpage, you can specify an item that should only apply to a directory by
+prefixing it with a 'D', or specify an item that should only apply to a
+file by prefixing it with a 'F'. For example, the following will ensure
+that all directories get marked set-gid, that no files are other-writable,
+that both are user-writable and group-writable, and that both have
+consistent executability across all bits:
+.RS 4
+.IP
+.nf
+--chmod=Dg+s,ug+w,Fo-w,+X
+.fi
+.RE
+.IP
+Using octal mode numbers is also allowed:
+.RS 4
+.IP
+.nf
+--chmod=D2775,F664
+.fi
+.RE
+.IP
+It is also legal to specify multiple \fB\-\-chmod\fP options, as each additional
+option is just appended to the list of changes to make.
+.IP
+See the \fB\-\-perms\fP and \fB\-\-executability\fP options for how the
+resulting permission value can be applied to the files in the transfer.
+.IP "\fB\-\-owner\fP, \fB\-o\fP"
+This option causes rsync to set the owner of the destination file to be the
+same as the source file, but only if the receiving rsync is being run as
+the super-user (see also the \fB\-\-super\fP and \fB\-\-fake-super\fP
+options). Without this option, the owner of new and/or transferred files
+are set to the invoking user on the receiving side.
+.IP
+The preservation of ownership will associate matching names by default, but
+may fall back to using the ID number in some circumstances (see also the
+\fB\-\-numeric-ids\fP option for a full discussion).
+.IP "\fB\-\-group\fP, \fB\-g\fP"
+This option causes rsync to set the group of the destination file to be the
+same as the source file. If the receiving program is not running as the
+super-user (or if \fB\-\-no-super\fP was specified), only groups that the
+invoking user on the receiving side is a member of will be preserved.
+Without this option, the group is set to the default group of the invoking
+user on the receiving side.
+.IP
+The preservation of group information will associate matching names by
+default, but may fall back to using the ID number in some circumstances
+(see also the \fB\-\-numeric-ids\fP option for a full discussion).
+.IP "\fB\-\-devices\fP"
+This option causes rsync to transfer character and block device files to
+the remote system to recreate these devices. If the receiving rsync is not
+being run as the super-user, rsync silently skips creating the device files
+(see also the \fB\-\-super\fP and \fB\-\-fake-super\fP options).
+.IP
+By default, rsync generates a "non-regular file" warning for each device
+file encountered when this option is not set. You can silence the warning
+by specifying \fB\-\-info=nonreg0\fP.
+.IP "\fB\-\-specials\fP"
+This option causes rsync to transfer special files, such as named sockets
+and fifos. If the receiving rsync is not being run as the super-user,
+rsync silently skips creating the special files (see also the
+\fB\-\-super\fP and \fB\-\-fake-super\fP options).
+.IP
+By default, rsync generates a "non-regular file" warning for each special
+file encountered when this option is not set. You can silence the warning
+by specifying \fB\-\-info=nonreg0\fP.
+.IP "\fB\-D\fP"
+The \fB\-D\fP option is equivalent to "\fB\-\-devices\fP
+\fB\-\-specials\fP".
+.IP "\fB\-\-copy-devices\fP"
+This tells rsync to treat a device on the sending side as a regular file,
+allowing it to be copied to a normal destination file (or another device
+if \fB\-\-write-devices\fP was also specified).
+.IP
+This option is refused by default by an rsync daemon.
+.IP "\fB\-\-write-devices\fP"
+This tells rsync to treat a device on the receiving side as a regular file,
+allowing the writing of file data into a device.
+.IP
+This option implies the \fB\-\-inplace\fP option.
+.IP
+Be careful using this, as you should know what devices are present on the
+receiving side of the transfer, especially when running rsync as root.
+.IP
+This option is refused by default by an rsync daemon.
+.IP "\fB\-\-times\fP, \fB\-t\fP"
+This tells rsync to transfer modification times along with the files and
+update them on the remote system. Note that if this option is not used,
+the optimization that excludes files that have not been modified cannot be
+effective; in other words, a missing \fB\-t\fP (or \fB\-a\fP) will cause the
+next transfer to behave as if it used \fB\-\-ignore-times\fP (\fB\-I\fP),
+causing all files to be updated (though rsync's delta-transfer algorithm
+will make the update fairly efficient if the files haven't actually
+changed, you're much better off using \fB\-t\fP).
+.IP
+A modern rsync that is using transfer protocol 30 or 31 conveys a modify
+time using up to 8-bytes. If rsync is forced to speak an older protocol
+(perhaps due to the remote rsync being older than 3.0.0) a modify time is
+conveyed using 4-bytes. Prior to 3.2.7, these shorter values could convey
+a date range of 13-Dec-1901 to 19-Jan-2038. Beginning with 3.2.7, these
+4-byte values now convey a date range of 1-Jan-1970 to 7-Feb-2106. If you
+have files dated older than 1970, make sure your rsync executables are
+upgraded so that the full range of dates can be conveyed.
+.IP "\fB\-\-atimes\fP, \fB\-U\fP"
+This tells rsync to set the access (use) times of the destination files to
+the same value as the source files.
+.IP
+If repeated, it also sets the \fB\-\-open-noatime\fP option, which can help you
+to make the sending and receiving systems have the same access times on the
+transferred files without needing to run rsync an extra time after a file
+is transferred.
+.IP
+Note that some older rsync versions (prior to 3.2.0) may have been built
+with a pre-release \fB\-\-atimes\fP patch that does not imply
+\fB\-\-open-noatime\fP when this option is repeated.
+.IP "\fB\-\-open-noatime\fP"
+This tells rsync to open files with the O_NOATIME flag (on systems that
+support it) to avoid changing the access time of the files that are being
+transferred. If your OS does not support the O_NOATIME flag then rsync
+will silently ignore this option. Note also that some filesystems are
+mounted to avoid updating the atime on read access even without the
+O_NOATIME flag being set.
+.IP "\fB\-\-crtimes\fP, \fB\-N,\fP"
+This tells rsync to set the create times (newness) of the destination
+files to the same value as the source files.
+.IP "\fB\-\-omit-dir-times\fP, \fB\-O\fP"
+This tells rsync to omit directories when it is preserving modification,
+access, and create times. If NFS is sharing the directories on the receiving
+side, it is a good idea to use \fB\-O\fP. This option is inferred if you use
+\fB\-\-backup\fP without \fB\-\-backup-dir\fP.
+.IP
+This option also has the side-effect of avoiding early creation of missing
+sub-directories when incremental recursion is enabled, as discussed in the
+\fB\-\-inc-recursive\fP section.
+.IP "\fB\-\-omit-link-times\fP, \fB\-J\fP"
+This tells rsync to omit symlinks when it is preserving modification,
+access, and create times.
+.IP "\fB\-\-super\fP"
+This tells the receiving side to attempt super-user activities even if the
+receiving rsync wasn't run by the super-user. These activities include:
+preserving users via the \fB\-\-owner\fP option, preserving all groups
+(not just the current user's groups) via the \fB\-\-group\fP option, and
+copying devices via the \fB\-\-devices\fP option. This is useful for
+systems that allow such activities without being the super-user, and also
+for ensuring that you will get errors if the receiving side isn't being run
+as the super-user. To turn off super-user activities, the super-user can
+use \fB\-\-no-super\fP.
+.IP "\fB\-\-fake-super\fP"
+When this option is enabled, rsync simulates super-user activities by
+saving/restoring the privileged attributes via special extended attributes
+that are attached to each file (as needed). This includes the file's owner
+and group (if it is not the default), the file's device info (device &
+special files are created as empty text files), and any permission bits
+that we won't allow to be set on the real file (e.g. the real file gets
+u-s,g-s,o-t for safety) or that would limit the owner's access (since the
+real super-user can always access/change a file, the files we create can
+always be accessed/changed by the creating user). This option also handles
+ACLs (if \fB\-\-acls\fP was specified) and non-user extended attributes
+(if \fB\-\-xattrs\fP was specified).
+.IP
+This is a good way to backup data without using a super-user, and to store
+ACLs from incompatible systems.
+.IP
+The \fB\-\-fake-super\fP option only affects the side where the option is used.
+To affect the remote side of a remote-shell connection, use the
+\fB\-\-remote-option\fP (\fB\-M\fP) option:
+.RS 4
+.IP
+.nf
+rsync -av -M--fake-super /src/ host:/dest/
+.fi
+.RE
+.IP
+For a local copy, this option affects both the source and the destination.
+If you wish a local copy to enable this option just for the destination
+files, specify \fB\-M\-\-fake-super\fP. If you wish a local copy to enable this
+option just for the source files, combine \fB\-\-fake-super\fP with \fB\-M\-\-super\fP.
+.IP
+This option is overridden by both \fB\-\-super\fP and \fB\-\-no-super\fP.
+.IP
+See also the \fBfake\ super\fP setting in the
+daemon's rsyncd.conf file.
+.IP "\fB\-\-sparse\fP, \fB\-S\fP"
+Try to handle sparse files efficiently so they take up less space on the
+destination. If combined with \fB\-\-inplace\fP the file created might
+not end up with sparse blocks with some combinations of kernel version
+and/or filesystem type. If \fB\-\-whole-file\fP is in effect (e.g. for a
+local copy) then it will always work because rsync truncates the file prior
+to writing out the updated version.
+.IP
+Note that versions of rsync older than 3.1.3 will reject the combination of
+\fB\-\-sparse\fP and \fB\-\-inplace\fP.
+.IP "\fB\-\-preallocate\fP"
+This tells the receiver to allocate each destination file to its eventual
+size before writing data to the file. Rsync will only use the real
+filesystem-level preallocation support provided by Linux's \fBfallocate\fP(2)
+system call or Cygwin's \fBposix_fallocate\fP(3), not the slow glibc
+implementation that writes a null byte into each block.
+.IP
+Without this option, larger files may not be entirely contiguous on the
+filesystem, but with this option rsync will probably copy more slowly. If
+the destination is not an extent-supporting filesystem (such as ext4, xfs,
+NTFS, etc.), this option may have no positive effect at all.
+.IP
+If combined with \fB\-\-sparse\fP, the file will only have sparse blocks
+(as opposed to allocated sequences of null bytes) if the kernel version and
+filesystem type support creating holes in the allocated data.
+.IP "\fB\-\-dry-run\fP, \fB\-n\fP"
+This makes rsync perform a trial run that doesn't make any changes (and
+produces mostly the same output as a real run). It is most commonly used
+in combination with the \fB\-\-verbose\fP (\fB\-v\fP) and/or
+\fB\-\-itemize-changes\fP (\fB\-i\fP) options to see what an rsync command is
+going to do before one actually runs it.
+.IP
+The output of \fB\-\-itemize-changes\fP is supposed to be exactly the
+same on a dry run and a subsequent real run (barring intentional trickery
+and system call failures); if it isn't, that's a bug. Other output should
+be mostly unchanged, but may differ in some areas. Notably, a dry run does
+not send the actual data for file transfers, so \fB\-\-progress\fP has no
+effect, the "bytes sent", "bytes received", "literal data", and "matched
+data" statistics are too small, and the "speedup" value is equivalent to a
+run where no file transfers were needed.
+.IP "\fB\-\-whole-file\fP, \fB\-W\fP"
+This option disables rsync's delta-transfer algorithm, which causes all
+transferred files to be sent whole. The transfer may be faster if this
+option is used when the bandwidth between the source and destination
+machines is higher than the bandwidth to disk (especially when the "disk"
+is actually a networked filesystem). This is the default when both the
+source and destination are specified as local paths, but only if no
+batch-writing option is in effect.
+.IP "\fB\-\-no-whole-file\fP, \fB\-\-no-W\fP"
+Disable whole-file updating when it is enabled by default for a local
+transfer. This usually slows rsync down, but it can be useful if you are
+trying to minimize the writes to the destination file (if combined with
+\fB\-\-inplace\fP) or for testing the checksum-based update algorithm.
+.IP
+See also the \fB\-\-whole-file\fP option.
+.IP "\fB\-\-checksum-choice=STR\fP, \fB\-\-cc=STR\fP"
+This option overrides the checksum algorithms. If one algorithm name is
+specified, it is used for both the transfer checksums and (assuming
+\fB\-\-checksum\fP is specified) the pre-transfer checksums. If two
+comma-separated names are supplied, the first name affects the transfer
+checksums, and the second name affects the pre-transfer checksums (\fB\-c\fP).
+.IP
+The checksum options that you may be able to use are:
+.IP
+.RS
+.IP o
+\fBauto\fP (the default automatic choice)
+.IP o
+\fBxxh128\fP
+.IP o
+\fBxxh3\fP
+.IP o
+\fBxxh64\fP (aka \fBxxhash\fP)
+.IP o
+\fBmd5\fP
+.IP o
+\fBmd4\fP
+.IP o
+\fBsha1\fP
+.IP o
+\fBnone\fP
+.RE
+.IP
+Run \fBrsync\ \-\-version\fP to see the default checksum list compiled into your
+version (which may differ from the list above).
+.IP
+If "none" is specified for the first (or only) name, the \fB\-\-whole-file\fP
+option is forced on and no checksum verification is performed on the
+transferred data. If "none" is specified for the second (or only) name,
+the \fB\-\-checksum\fP option cannot be used.
+.IP
+The "auto" option is the default, where rsync bases its algorithm choice on
+a negotiation between the client and the server as follows:
+.IP
+When both sides of the transfer are at least 3.2.0, rsync chooses the first
+algorithm in the client's list of choices that is also in the server's list
+of choices. If no common checksum choice is found, rsync exits with
+an error. If the remote rsync is too old to support checksum negotiation,
+a value is chosen based on the protocol version (which chooses between MD5
+and various flavors of MD4 based on protocol age).
+.IP
+The default order can be customized by setting the environment variable
+\fBRSYNC_CHECKSUM_LIST\fP to a space-separated list of acceptable checksum
+names. If the string contains a "\fB&\fP" character, it is separated into the
+"client string & server string", otherwise the same string applies to both.
+If the string (or string portion) contains no non-whitespace characters,
+the default checksum list is used. This method does not allow you to
+specify the transfer checksum separately from the pre-transfer checksum,
+and it discards "auto" and all unknown checksum names. A list with only
+invalid names results in a failed negotiation.
+.IP
+The use of the \fB\-\-checksum-choice\fP option overrides this environment list.
+.IP "\fB\-\-one-file-system\fP, \fB\-x\fP"
+This tells rsync to avoid crossing a filesystem boundary when recursing.
+This does not limit the user's ability to specify items to copy from
+multiple filesystems, just rsync's recursion through the hierarchy of each
+directory that the user specified, and also the analogous recursion on the
+receiving side during deletion. Also keep in mind that rsync treats a
+"bind" mount to the same device as being on the same filesystem.
+.IP
+If this option is repeated, rsync omits all mount-point directories from
+the copy. Otherwise, it includes an empty directory at each mount-point it
+encounters (using the attributes of the mounted directory because those of
+the underlying mount-point directory are inaccessible).
+.IP
+If rsync has been told to collapse symlinks (via \fB\-\-copy-links\fP or
+\fB\-\-copy-unsafe-links\fP), a symlink to a directory on another device
+is treated like a mount-point. Symlinks to non-directories are unaffected
+by this option.
+.IP "\fB\-\-ignore-non-existing\fP, \fB\-\-existing\fP"
+This tells rsync to skip creating files (including directories) that do not
+exist yet on the destination. If this option is combined with the
+\fB\-\-ignore-existing\fP option, no files will be updated (which can be
+useful if all you want to do is delete extraneous files).
+.IP
+This option is a TRANSFER RULE, so don't expect any
+exclude side effects.
+.IP "\fB\-\-ignore-existing\fP"
+This tells rsync to skip updating files that already exist on the
+destination (this does \fInot\fP ignore existing directories, or nothing would
+get done). See also \fB\-\-ignore-non-existing\fP.
+.IP
+This option is a TRANSFER RULE, so don't expect any
+exclude side effects.
+.IP
+This option can be useful for those doing backups using the
+\fB\-\-link-dest\fP option when they need to continue a backup run that
+got interrupted. Since a \fB\-\-link-dest\fP run is copied into a new
+directory hierarchy (when it is used properly), using [\fB\-\-ignore-existing\fP
+will ensure that the already-handled files don't get tweaked (which avoids
+a change in permissions on the hard-linked files). This does mean that
+this option is only looking at the existing files in the destination
+hierarchy itself.
+.IP
+When \fB\-\-info=skip2\fP is used rsync will output "FILENAME exists
+(INFO)" messages where the INFO indicates one of "type change", "sum
+change" (requires \fB\-c\fP), "file change" (based on the quick check),
+"attr change", or "uptodate". Using \fB\-\-info=skip1\fP (which is also
+implied by 2 \fB\-v\fP options) outputs the exists message without the
+INFO suffix.
+.IP "\fB\-\-remove-source-files\fP"
+This tells rsync to remove from the sending side the files (meaning
+non-directories) that are a part of the transfer and have been successfully
+duplicated on the receiving side.
+.IP
+Note that you should only use this option on source files that are
+quiescent. If you are using this to move files that show up in a
+particular directory over to another host, make sure that the finished
+files get renamed into the source directory, not directly written into it,
+so that rsync can't possibly transfer a file that is not yet fully written.
+If you can't first write the files into a different directory, you should
+use a naming idiom that lets rsync avoid transferring files that are not
+yet finished (e.g. name the file "foo.new" when it is written, rename it to
+"foo" when it is done, and then use the option \fB\-\-exclude='*.new'\fP
+for the rsync transfer).
+.IP
+Starting with 3.1.0, rsync will skip the sender-side removal (and output an
+error) if the file's size or modify time has not stayed unchanged.
+.IP
+Starting with 3.2.6, a local rsync copy will ensure that the sender does
+not remove a file the receiver just verified, such as when the user
+accidentally makes the source and destination directory the same path.
+.IP "\fB\-\-delete\fP"
+This tells rsync to delete extraneous files from the receiving side (ones
+that aren't on the sending side), but only for the directories that are
+being synchronized. You must have asked rsync to send the whole directory
+(e.g. "\fBdir\fP" or "\fBdir/\fP") without using a wildcard for the directory's
+contents (e.g. "\fBdir/*\fP") since the wildcard is expanded by the shell and
+rsync thus gets a request to transfer individual files, not the files'
+parent directory. Files that are excluded from the transfer are also
+excluded from being deleted unless you use the \fB\-\-delete-excluded\fP
+option or mark the rules as only matching on the sending side (see the
+include/exclude modifiers in the FILTER RULES section).
+.IP
+Prior to rsync 2.6.7, this option would have no effect unless
+\fB\-\-recursive\fP was enabled. Beginning with 2.6.7, deletions will
+also occur when \fB\-\-dirs\fP (\fB\-d\fP) is enabled, but only for
+directories whose contents are being copied.
+.IP
+This option can be dangerous if used incorrectly! It is a very good idea to
+first try a run using the \fB\-\-dry-run\fP (\fB\-n\fP) option to see what
+files are going to be deleted.
+.IP
+If the sending side detects any I/O errors, then the deletion of any files
+at the destination will be automatically disabled. This is to prevent
+temporary filesystem failures (such as NFS errors) on the sending side from
+causing a massive deletion of files on the destination. You can override
+this with the \fB\-\-ignore-errors\fP option.
+.IP
+The \fB\-\-delete\fP option may be combined with one of the \-\-delete-WHEN options
+without conflict, as well as \fB\-\-delete-excluded\fP. However, if none
+of the \fB\-\-delete-WHEN\fP options are specified, rsync will choose the
+\fB\-\-delete-during\fP algorithm when talking to rsync 3.0.0 or newer,
+or the \fB\-\-delete-before\fP algorithm when talking to an older rsync.
+See also \fB\-\-delete-delay\fP and \fB\-\-delete-after\fP.
+.IP "\fB\-\-delete-before\fP"
+Request that the file-deletions on the receiving side be done before the
+transfer starts. See \fB\-\-delete\fP (which is implied) for more
+details on file-deletion.
+.IP
+Deleting before the transfer is helpful if the filesystem is tight for
+space and removing extraneous files would help to make the transfer
+possible. However, it does introduce a delay before the start of the
+transfer, and this delay might cause the transfer to timeout (if
+\fB\-\-timeout\fP was specified). It also forces rsync to use the old,
+non-incremental recursion algorithm that requires rsync to scan all the
+files in the transfer into memory at once (see \fB\-\-recursive\fP).
+.IP "\fB\-\-delete-during\fP, \fB\-\-del\fP"
+Request that the file-deletions on the receiving side be done incrementally
+as the transfer happens. The per-directory delete scan is done right
+before each directory is checked for updates, so it behaves like a more
+efficient \fB\-\-delete-before\fP, including doing the deletions prior to
+any per-directory filter files being updated. This option was first added
+in rsync version 2.6.4. See \fB\-\-delete\fP (which is implied) for more
+details on file-deletion.
+.IP "\fB\-\-delete-delay\fP"
+Request that the file-deletions on the receiving side be computed during
+the transfer (like \fB\-\-delete-during\fP), and then removed after the
+transfer completes. This is useful when combined with
+\fB\-\-delay-updates\fP and/or \fB\-\-fuzzy\fP, and is more efficient
+than using \fB\-\-delete-after\fP (but can behave differently, since
+\fB\-\-delete-after\fP computes the deletions in a separate pass after
+all updates are done). If the number of removed files overflows an
+internal buffer, a temporary file will be created on the receiving side to
+hold the names (it is removed while open, so you shouldn't see it during
+the transfer). If the creation of the temporary file fails, rsync will try
+to fall back to using \fB\-\-delete-after\fP (which it cannot do if
+\fB\-\-recursive\fP is doing an incremental scan). See
+\fB\-\-delete\fP (which is implied) for more details on file-deletion.
+.IP "\fB\-\-delete-after\fP"
+Request that the file-deletions on the receiving side be done after the
+transfer has completed. This is useful if you are sending new
+per-directory merge files as a part of the transfer and you want their
+exclusions to take effect for the delete phase of the current transfer. It
+also forces rsync to use the old, non-incremental recursion algorithm that
+requires rsync to scan all the files in the transfer into memory at once
+(see \fB\-\-recursive\fP). See \fB\-\-delete\fP (which is implied) for
+more details on file-deletion.
+.IP
+See also the \fB\-\-delete-delay\fP option that might be a faster choice
+for those that just want the deletions to occur at the end of the transfer.
+.IP "\fB\-\-delete-excluded\fP"
+This option turns any unqualified exclude/include rules into server-side
+rules that do not affect the receiver's deletions.
+.IP
+By default, an exclude or include has both a server-side effect (to "hide"
+and "show" files when building the server's file list) and a receiver-side
+effect (to "protect" and "risk" files when deletions are occurring). Any
+rule that has no modifier to specify what sides it is executed on will be
+instead treated as if it were a server-side rule only, avoiding any
+"protect" effects of the rules.
+.IP
+A rule can still apply to both sides even with this option specified if the
+rule is given both the sender & receiver modifier letters (e.g., \fB\-f'\-sr\ foo'\fP). Receiver-side protect/risk rules can also be explicitly specified
+to limit the deletions. This saves you from having to edit a bunch of
+\fB\-f'\-\ foo'\fP rules into \fB\-f'\-s\ foo'\fP (aka \fB\-f'H\ foo'\fP) rules (not to mention
+the corresponding includes).
+.IP
+See the FILTER RULES section for more information. See
+\fB\-\-delete\fP (which is implied) for more details on deletion.
+.IP "\fB\-\-ignore-missing-args\fP"
+When rsync is first processing the explicitly requested source files (e.g.
+command-line arguments or \fB\-\-files-from\fP entries), it is normally
+an error if the file cannot be found. This option suppresses that error,
+and does not try to transfer the file. This does not affect subsequent
+vanished-file errors if a file was initially found to be present and later
+is no longer there.
+.IP "\fB\-\-delete-missing-args\fP"
+This option takes the behavior of the (implied)
+\fB\-\-ignore-missing-args\fP option a step farther: each missing arg
+will become a deletion request of the corresponding destination file on the
+receiving side (should it exist). If the destination file is a non-empty
+directory, it will only be successfully deleted if \fB\-\-force\fP or
+\fB\-\-delete\fP are in effect. Other than that, this option is
+independent of any other type of delete processing.
+.IP
+The missing source files are represented by special file-list entries which
+display as a "\fB*missing\fP" entry in the \fB\-\-list-only\fP output.
+.IP "\fB\-\-ignore-errors\fP"
+Tells \fB\-\-delete\fP to go ahead and delete files even when there are
+I/O errors.
+.IP "\fB\-\-force\fP"
+This option tells rsync to delete a non-empty directory when it is to be
+replaced by a non-directory. This is only relevant if deletions are not
+active (see \fB\-\-delete\fP for details).
+.IP
+Note for older rsync versions: \fB\-\-force\fP used to still be required when
+using \fB\-\-delete-after\fP, and it used to be non-functional unless the
+\fB\-\-recursive\fP option was also enabled.
+.IP "\fB\-\-max-delete=NUM\fP"
+This tells rsync not to delete more than NUM files or directories. If that
+limit is exceeded, all further deletions are skipped through the end of the
+transfer. At the end, rsync outputs a warning (including a count of the
+skipped deletions) and exits with an error code of 25 (unless some more
+important error condition also occurred).
+.IP
+Beginning with version 3.0.0, you may specify \fB\-\-max-delete=0\fP to be warned
+about any extraneous files in the destination without removing any of them.
+Older clients interpreted this as "unlimited", so if you don't know what
+version the client is, you can use the less obvious \fB\-\-max-delete=\-1\fP as a
+backward-compatible way to specify that no deletions be allowed (though
+really old versions didn't warn when the limit was exceeded).
+.IP "\fB\-\-max-size=SIZE\fP"
+This tells rsync to avoid transferring any file that is larger than the
+specified SIZE. A numeric value can be suffixed with a string to indicate
+the numeric units or left unqualified to specify bytes. Feel free to use a
+fractional value along with the units, such as \fB\-\-max-size=1.5m\fP.
+.IP
+This option is a TRANSFER RULE, so don't expect any
+exclude side effects.
+.IP
+The first letter of a units string can be \fBB\fP (bytes), \fBK\fP (kilo), \fBM\fP
+(mega), \fBG\fP (giga), \fBT\fP (tera), or \fBP\fP (peta). If the string is a single
+char or has "ib" added to it (e.g. "G" or "GiB") then the units are
+multiples of 1024. If you use a two-letter suffix that ends with a "B"
+(e.g. "kb") then you get units that are multiples of 1000. The string's
+letters can be any mix of upper and lower-case that you want to use.
+.IP
+Finally, if the string ends with either "+1" or "\-1", it is offset by one
+byte in the indicated direction. The largest possible value is usually
+\fB8192P-1\fP.
+.IP
+Examples: \fB\-\-max-size=1.5mb-1\fP is 1499999 bytes, and \fB\-\-max-size=2g+1\fP is
+2147483649 bytes.
+.IP
+Note that rsync versions prior to 3.1.0 did not allow \fB\-\-max-size=0\fP.
+.IP "\fB\-\-min-size=SIZE\fP"
+This tells rsync to avoid transferring any file that is smaller than the
+specified SIZE, which can help in not transferring small, junk files. See
+the \fB\-\-max-size\fP option for a description of SIZE and other info.
+.IP
+Note that rsync versions prior to 3.1.0 did not allow \fB\-\-min-size=0\fP.
+.IP "\fB\-\-max-alloc=SIZE\fP"
+By default rsync limits an individual malloc/realloc to about 1GB in size.
+For most people this limit works just fine and prevents a protocol error
+causing rsync to request massive amounts of memory. However, if you have
+many millions of files in a transfer, a large amount of server memory, and
+you don't want to split up your transfer into multiple parts, you can
+increase the per-allocation limit to something larger and rsync will
+consume more memory.
+.IP
+Keep in mind that this is not a limit on the total size of allocated
+memory. It is a sanity-check value for each individual allocation.
+.IP
+See the \fB\-\-max-size\fP option for a description of how SIZE can be
+specified. The default suffix if none is given is bytes.
+.IP
+Beginning in 3.2.3, a value of 0 specifies no limit.
+.IP
+You can set a default value using the environment variable
+\fBRSYNC_MAX_ALLOC\fP using the same SIZE values as supported by this
+option. If the remote rsync doesn't understand the \fB\-\-max-alloc\fP option,
+you can override an environmental value by specifying \fB\-\-max-alloc=1g\fP,
+which will make rsync avoid sending the option to the remote side (because
+"1G" is the default).
+.IP "\fB\-\-block-size=SIZE\fP, \fB\-B\fP"
+This forces the block size used in rsync's delta-transfer algorithm to a
+fixed value. It is normally selected based on the size of each file being
+updated. See the technical report for details.
+.IP
+Beginning in 3.2.3 the SIZE can be specified with a suffix as detailed in
+the \fB\-\-max-size\fP option. Older versions only accepted a byte count.
+.IP "\fB\-\-rsh=COMMAND\fP, \fB\-e\fP"
+This option allows you to choose an alternative remote shell program to use
+for communication between the local and remote copies of rsync. Typically,
+rsync is configured to use ssh by default, but you may prefer to use rsh on
+a local network.
+.IP
+If this option is used with \fB[user@]host::module/path\fP, then the remote
+shell \fICOMMAND\fP will be used to run an rsync daemon on the remote host, and
+all data will be transmitted through that remote shell connection, rather
+than through a direct socket connection to a running rsync daemon on the
+remote host. See the USING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL
+CONNECTION section above.
+.IP
+Beginning with rsync 3.2.0, the \fBRSYNC_PORT\fP environment variable will
+be set when a daemon connection is being made via a remote-shell
+connection. It is set to 0 if the default daemon port is being assumed, or
+it is set to the value of the rsync port that was specified via either the
+\fB\-\-port\fP option or a non-empty port value in an \fBrsync://\fP URL.
+This allows the script to discern if a non-default port is being requested,
+allowing for things such as an SSL or stunnel helper script to connect to a
+default or alternate port.
+.IP
+Command-line arguments are permitted in COMMAND provided that COMMAND is
+presented to rsync as a single argument. You must use spaces (not tabs or
+other whitespace) to separate the command and args from each other, and you
+can use single- and/or double-quotes to preserve spaces in an argument (but
+not backslashes). Note that doubling a single-quote inside a single-quoted
+string gives you a single-quote; likewise for double-quotes (though you
+need to pay attention to which quotes your shell is parsing and which
+quotes rsync is parsing). Some examples:
+.RS 4
+.IP
+.nf
+-e 'ssh -p 2234'
+-e 'ssh -o "ProxyCommand nohup ssh firewall nc -w1 %h %p"'
+.fi
+.RE
+.IP
+(Note that ssh users can alternately customize site-specific connect
+options in their .ssh/config file.)
+.IP
+You can also choose the remote shell program using the \fBRSYNC_RSH\fP
+environment variable, which accepts the same range of values as \fB\-e\fP.
+.IP
+See also the \fB\-\-blocking-io\fP option which is affected by this
+option.
+.IP "\fB\-\-rsync-path=PROGRAM\fP"
+Use this to specify what program is to be run on the remote machine to
+start-up rsync. Often used when rsync is not in the default remote-shell's
+path (e.g. \fB\-\-rsync-path=/usr/local/bin/rsync\fP). Note that PROGRAM is run
+with the help of a shell, so it can be any program, script, or command
+sequence you'd care to run, so long as it does not corrupt the standard-in
+& standard-out that rsync is using to communicate.
+.IP
+One tricky example is to set a different default directory on the remote
+machine for use with the \fB\-\-relative\fP option. For instance:
+.RS 4
+.IP
+.nf
+rsync -avR --rsync-path="cd /a/b && rsync" host:c/d /e/
+.fi
+.RE
+.IP "\fB\-\-remote-option=OPTION\fP, \fB\-M\fP"
+This option is used for more advanced situations where you want certain
+effects to be limited to one side of the transfer only. For instance, if
+you want to pass \fB\-\-log-file=FILE\fP and \fB\-\-fake-super\fP to
+the remote system, specify it like this:
+.RS 4
+.IP
+.nf
+rsync -av -M --log-file=foo -M--fake-super src/ dest/
+.fi
+.RE
+.IP
+If you want to have an option affect only the local side of a transfer when
+it normally affects both sides, send its negation to the remote side. Like
+this:
+.RS 4
+.IP
+.nf
+rsync -av -x -M--no-x src/ dest/
+.fi
+.RE
+.IP
+Be cautious using this, as it is possible to toggle an option that will
+cause rsync to have a different idea about what data to expect next over
+the socket, and that will make it fail in a cryptic fashion.
+.IP
+Note that you should use a separate \fB\-M\fP option for each remote option you
+want to pass. On older rsync versions, the presence of any spaces in the
+remote-option arg could cause it to be split into separate remote args, but
+this requires the use of \fB\-\-old-args\fP in a modern rsync.
+.IP
+When performing a local transfer, the "local" side is the sender and the
+"remote" side is the receiver.
+.IP
+Note some versions of the popt option-parsing library have a bug in them
+that prevents you from using an adjacent arg with an equal in it next to a
+short option letter (e.g. \fB\-M\-\-log-file=/tmp/foo\fP). If this bug affects
+your version of popt, you can use the version of popt that is included with
+rsync.
+.IP "\fB\-\-cvs-exclude\fP, \fB\-C\fP"
+This is a useful shorthand for excluding a broad range of files that you
+often don't want to transfer between systems. It uses a similar algorithm
+to CVS to determine if a file should be ignored.
+.IP
+The exclude list is initialized to exclude the following items (these
+initial items are marked as perishable\ \-\- see the FILTER RULES
+section):
+.RS 4
+.IP
+\fBRCS\fP
+\fBSCCS\fP
+\fBCVS\fP
+\fBCVS.adm\fP
+\fBRCSLOG\fP
+\fBcvslog.*\fP
+\fBtags\fP
+\fBTAGS\fP
+\fB.make.state\fP
+\fB.nse_depinfo\fP
+\fB*~\fP
+\fB#*\fP
+\fB.#*\fP
+\fB,*\fP
+\fB_$*\fP
+\fB*$\fP
+\fB*.old\fP
+\fB*.bak\fP
+\fB*.BAK\fP
+\fB*.orig\fP
+\fB*.rej\fP
+\fB.del-*\fP
+\fB*.a\fP
+\fB*.olb\fP
+\fB*.o\fP
+\fB*.obj\fP
+\fB*.so\fP
+\fB*.exe\fP
+\fB*.Z\fP
+\fB*.elc\fP
+\fB*.ln\fP
+\fBcore\fP
+\fB.svn/\fP
+\fB.git/\fP
+\fB.hg/\fP
+\fB.bzr/\fP
+.RE
+.IP
+then, files listed in a $HOME/.cvsignore are added to the list and any
+files listed in the CVSIGNORE environment variable (all cvsignore names are
+delimited by whitespace).
+.IP
+Finally, any file is ignored if it is in the same directory as a .cvsignore
+file and matches one of the patterns listed therein. Unlike rsync's
+filter/exclude files, these patterns are split on whitespace. See the
+\fBcvs\fP(1) manual for more information.
+.IP
+If you're combining \fB\-C\fP with your own \fB\-\-filter\fP rules, you should
+note that these CVS excludes are appended at the end of your own rules,
+regardless of where the \fB\-C\fP was placed on the command-line. This makes
+them a lower priority than any rules you specified explicitly. If you want
+to control where these CVS excludes get inserted into your filter rules,
+you should omit the \fB\-C\fP as a command-line option and use a combination of
+\fB\-\-filter=:C\fP and \fB\-\-filter=\-C\fP (either on your
+command-line or by putting the ":C" and "\-C" rules into a filter file with
+your other rules). The first option turns on the per-directory scanning
+for the .cvsignore file. The second option does a one-time import of the
+CVS excludes mentioned above.
+.IP "\fB\-\-filter=RULE\fP, \fB\-f\fP"
+This option allows you to add rules to selectively exclude certain files
+from the list of files to be transferred. This is most useful in
+combination with a recursive transfer.
+.IP
+You may use as many \fB\-\-filter\fP options on the command line as you like to
+build up the list of files to exclude. If the filter contains whitespace,
+be sure to quote it so that the shell gives the rule to rsync as a single
+argument. The text below also mentions that you can use an underscore to
+replace the space that separates a rule from its arg.
+.IP
+See the FILTER RULES section for detailed information on this option.
+.IP "\fB\-F\fP"
+The \fB\-F\fP option is a shorthand for adding two \fB\-\-filter\fP rules to
+your command. The first time it is used is a shorthand for this rule:
+.RS 4
+.IP
+.nf
+--filter='dir-merge /.rsync-filter'
+.fi
+.RE
+.IP
+This tells rsync to look for per-directory .rsync-filter files that have
+been sprinkled through the hierarchy and use their rules to filter the
+files in the transfer. If \fB\-F\fP is repeated, it is a shorthand for this
+rule:
+.RS 4
+.IP
+.nf
+--filter='exclude .rsync-filter'
+.fi
+.RE
+.IP
+This filters out the .rsync-filter files themselves from the transfer.
+.IP
+See the FILTER RULES section for detailed information on how these
+options work.
+.IP "\fB\-\-exclude=PATTERN\fP"
+This option is a simplified form of the \fB\-\-filter\fP option that
+specifies an exclude rule and does not allow the full rule-parsing syntax
+of normal filter rules. This is equivalent to specifying \fB\-f'\-\ PATTERN'\fP.
+.IP
+See the FILTER RULES section for detailed information on this option.
+.IP "\fB\-\-exclude-from=FILE\fP"
+This option is related to the \fB\-\-exclude\fP option, but it specifies
+a FILE that contains exclude patterns (one per line). Blank lines in the
+file are ignored, as are whole-line comments that start with '\fB;\fP' or '\fB#\fP'
+(filename rules that contain those characters are unaffected).
+.IP
+If a line begins with "\fB\-\ \fP" (dash, space) or "\fB+\ \fP" (plus, space), then
+the type of rule is being explicitly specified as an exclude or an include
+(respectively). Any rules without such a prefix are taken to be an exclude.
+.IP
+If a line consists of just "\fB!\fP", then the current filter rules are cleared
+before adding any further rules.
+.IP
+If \fIFILE\fP is '\fB\-\fP', the list will be read from standard input.
+.IP "\fB\-\-include=PATTERN\fP"
+This option is a simplified form of the \fB\-\-filter\fP option that
+specifies an include rule and does not allow the full rule-parsing syntax
+of normal filter rules. This is equivalent to specifying \fB\-f'+\ PATTERN'\fP.
+.IP
+See the FILTER RULES section for detailed information on this option.
+.IP "\fB\-\-include-from=FILE\fP"
+This option is related to the \fB\-\-include\fP option, but it specifies
+a FILE that contains include patterns (one per line). Blank lines in the
+file are ignored, as are whole-line comments that start with '\fB;\fP' or '\fB#\fP'
+(filename rules that contain those characters are unaffected).
+.IP
+If a line begins with "\fB\-\ \fP" (dash, space) or "\fB+\ \fP" (plus, space), then
+the type of rule is being explicitly specified as an exclude or an include
+(respectively). Any rules without such a prefix are taken to be an include.
+.IP
+If a line consists of just "\fB!\fP", then the current filter rules are cleared
+before adding any further rules.
+.IP
+If \fIFILE\fP is '\fB\-\fP', the list will be read from standard input.
+.IP "\fB\-\-files-from=FILE\fP"
+Using this option allows you to specify the exact list of files to transfer
+(as read from the specified FILE or '\fB\-\fP' for standard input). It also
+tweaks the default behavior of rsync to make transferring just the
+specified files and directories easier:
+.IP
+.RS
+.IP o
+The \fB\-\-relative\fP (\fB\-R\fP) option is implied, which preserves the
+path information that is specified for each item in the file (use
+\fB\-\-no-relative\fP or \fB\-\-no-R\fP if you want to turn that off).
+.IP o
+The \fB\-\-dirs\fP (\fB\-d\fP) option is implied, which will create
+directories specified in the list on the destination rather than noisily
+skipping them (use \fB\-\-no-dirs\fP or \fB\-\-no-d\fP if you want to turn that off).
+.IP o
+The \fB\-\-archive\fP (\fB\-a\fP) option's behavior does not imply
+\fB\-\-recursive\fP (\fB\-r\fP), so specify it explicitly, if you want it.
+.IP o
+These side-effects change the default state of rsync, so the position of
+the \fB\-\-files-from\fP option on the command-line has no bearing on how other
+options are parsed (e.g. \fB\-a\fP works the same before or after
+\fB\-\-files-from\fP, as does \fB\-\-no-R\fP and all other options).
+.RE
+.IP
+The filenames that are read from the FILE are all relative to the source
+dir\ \-\- any leading slashes are removed and no ".." references are allowed
+to go higher than the source dir. For example, take this command:
+.RS 4
+.IP
+.nf
+rsync -a --files-from=/tmp/foo /usr remote:/backup
+.fi
+.RE
+.IP
+If /tmp/foo contains the string "bin" (or even "/bin"), the /usr/bin
+directory will be created as /backup/bin on the remote host. If it
+contains "bin/" (note the trailing slash), the immediate contents of the
+directory would also be sent (without needing to be explicitly mentioned in
+the file\ \-\- this began in version 2.6.4). In both cases, if the
+\fB\-r\fP option was enabled, that dir's entire hierarchy would also be
+transferred (keep in mind that \fB\-r\fP needs to be specified
+explicitly with \fB\-\-files-from\fP, since it is not implied by \fB\-a\fP.
+Also note that the effect of the (enabled by default) \fB\-r\fP option
+is to duplicate only the path info that is read from the file\ \-\- it does
+not force the duplication of the source-spec path (/usr in this case).
+.IP
+In addition, the \fB\-\-files-from\fP file can be read from the remote host
+instead of the local host if you specify a "host:" in front of the file
+(the host must match one end of the transfer). As a short-cut, you can
+specify just a prefix of ":" to mean "use the remote end of the transfer".
+For example:
+.RS 4
+.IP
+.nf
+rsync -a --files-from=:/path/file-list src:/ /tmp/copy
+.fi
+.RE
+.IP
+This would copy all the files specified in the /path/file-list file that
+was located on the remote "src" host.
+.IP
+If the \fB\-\-iconv\fP and \fB\-\-secluded-args\fP options are specified
+and the \fB\-\-files-from\fP filenames are being sent from one host to another,
+the filenames will be translated from the sending host's charset to the
+receiving host's charset.
+.IP
+NOTE: sorting the list of files in the \fB\-\-files-from\fP input helps rsync to
+be more efficient, as it will avoid re-visiting the path elements that are
+shared between adjacent entries. If the input is not sorted, some path
+elements (implied directories) may end up being scanned multiple times, and
+rsync will eventually unduplicate them after they get turned into file-list
+elements.
+.IP "\fB\-\-from0\fP, \fB\-0\fP"
+This tells rsync that the rules/filenames it reads from a file are
+terminated by a null ('\\0') character, not a NL, CR, or CR+LF. This
+affects \fB\-\-exclude-from\fP, \fB\-\-include-from\fP,
+\fB\-\-files-from\fP, and any merged files specified in a
+\fB\-\-filter\fP rule. It does not affect \fB\-\-cvs-exclude\fP (since
+all names read from a .cvsignore file are split on whitespace).
+.IP "\fB\-\-old-args\fP"
+This option tells rsync to stop trying to protect the arg values on the
+remote side from unintended word-splitting or other misinterpretation.
+It also allows the client to treat an empty arg as a "." instead of
+generating an error.
+.IP
+The default in a modern rsync is for "shell-active" characters (including
+spaces) to be backslash-escaped in the args that are sent to the remote
+shell. The wildcard characters \fB*\fP, \fB?\fP, \fB[\fP, & \fB]\fP are not escaped in
+filename args (allowing them to expand into multiple filenames) while being
+protected in option args, such as \fB\-\-usermap\fP.
+.IP
+If you have a script that wants to use old-style arg splitting in its
+filenames, specify this option once. If the remote shell has a problem
+with any backslash escapes at all, specify this option twice.
+.IP
+You may also control this setting via the \fBRSYNC_OLD_ARGS\fP environment
+variable. If it has the value "1", rsync will default to a single-option
+setting. If it has the value "2" (or more), rsync will default to a
+repeated-option setting. If it is "0", you'll get the default escaping
+behavior. The environment is always overridden by manually specified
+positive or negative options (the negative is \fB\-\-no-old-args\fP).
+.IP
+Note that this option also disables the extra safety check added in 3.2.5
+that ensures that a remote sender isn't including extra top-level items in
+the file-list that you didn't request. This side-effect is necessary
+because we can't know for sure what names to expect when the remote shell
+is interpreting the args.
+.IP
+This option conflicts with the \fB\-\-secluded-args\fP option.
+.IP "\fB\-\-secluded-args\fP, \fB\-s\fP"
+This option sends all filenames and most options to the remote rsync via
+the protocol (not the remote shell command line) which avoids letting the
+remote shell modify them. Wildcards are expanded on the remote host by
+rsync instead of a shell.
+.IP
+This is similar to the default backslash-escaping of args that was added
+in 3.2.4 (see \fB\-\-old-args\fP) in that it prevents things like space
+splitting and unwanted special-character side-effects. However, it has the
+drawbacks of being incompatible with older rsync versions (prior to 3.0.0)
+and of being refused by restricted shells that want to be able to inspect
+all the option values for safety.
+.IP
+This option is useful for those times that you need the argument's
+character set to be converted for the remote host, if the remote shell is
+incompatible with the default backslash-escpaing method, or there is some
+other reason that you want the majority of the options and arguments to
+bypass the command-line of the remote shell.
+.IP
+If you combine this option with \fB\-\-iconv\fP, the args related to the
+remote side will be translated from the local to the remote character-set.
+The translation happens before wild-cards are expanded. See also the
+\fB\-\-files-from\fP option.
+.IP
+You may also control this setting via the \fBRSYNC_PROTECT_ARGS\fP
+environment variable. If it has a non-zero value, this setting will be
+enabled by default, otherwise it will be disabled by default. Either state
+is overridden by a manually specified positive or negative version of this
+option (note that \fB\-\-no-s\fP and \fB\-\-no-secluded-args\fP are the negative
+versions). This environment variable is also superseded by a non-zero
+\fBRSYNC_OLD_ARGS\fP export.
+.IP
+This option conflicts with the \fB\-\-old-args\fP option.
+.IP
+This option used to be called \fB\-\-protect-args\fP (before 3.2.6) and that
+older name can still be used (though specifying it as \fB\-s\fP is always the
+easiest and most compatible choice).
+.IP "\fB\-\-trust-sender\fP"
+This option disables two extra validation checks that a local client
+performs on the file list generated by a remote sender. This option should
+only be used if you trust the sender to not put something malicious in the
+file list (something that could possibly be done via a modified rsync, a
+modified shell, or some other similar manipulation).
+.IP
+Normally, the rsync client (as of version 3.2.5) runs two extra validation
+checks when pulling files from a remote rsync:
+.IP
+.RS
+.IP o
+It verifies that additional arg items didn't get added at the top of the
+transfer.
+.IP o
+It verifies that none of the items in the file list are names that should
+have been excluded (if filter rules were specified).
+.RE
+.IP
+Note that various options can turn off one or both of these checks if the
+option interferes with the validation. For instance:
+.IP
+.RS
+.IP o
+Using a per-directory filter file reads filter rules that only the server
+knows about, so the filter checking is disabled.
+.IP o
+Using the \fB\-\-old-args\fP option allows the sender to manipulate the
+requested args, so the arg checking is disabled.
+.IP o
+Reading the files-from list from the server side means that the client
+doesn't know the arg list, so the arg checking is disabled.
+.IP o
+Using \fB\-\-read-batch\fP disables both checks since the batch file's
+contents will have been verified when it was created.
+.RE
+.IP
+This option may help an under-powered client server if the extra pattern
+matching is slowing things down on a huge transfer. It can also be used to
+work around a currently-unknown bug in the verification logic for a transfer
+from a trusted sender.
+.IP
+When using this option it is a good idea to specify a dedicated destination
+directory, as discussed in the MULTI-HOST SECURITY section.
+.IP "\fB\-\-copy-as=USER[:GROUP]\fP"
+This option instructs rsync to use the USER and (if specified after a
+colon) the GROUP for the copy operations. This only works if the user that
+is running rsync has the ability to change users. If the group is not
+specified then the user's default groups are used.
+.IP
+This option can help to reduce the risk of an rsync being run as root into
+or out of a directory that might have live changes happening to it and you
+want to make sure that root-level read or write actions of system files are
+not possible. While you could alternatively run all of rsync as the
+specified user, sometimes you need the root-level host-access credentials
+to be used, so this allows rsync to drop root for the copying part of the
+operation after the remote-shell or daemon connection is established.
+.IP
+The option only affects one side of the transfer unless the transfer is
+local, in which case it affects both sides. Use the
+\fB\-\-remote-option\fP to affect the remote side, such as
+\fB\-M\-\-copy-as=joe\fP. For a local transfer, the lsh (or lsh.sh) support file
+provides a local-shell helper script that can be used to allow a
+"localhost:" or "lh:" host-spec to be specified without needing to setup
+any remote shells, allowing you to specify remote options that affect the
+side of the transfer that is using the host-spec (and using hostname "lh"
+avoids the overriding of the remote directory to the user's home dir).
+.IP
+For example, the following rsync writes the local files as user "joe":
+.RS 4
+.IP
+.nf
+sudo rsync -aiv --copy-as=joe host1:backups/joe/ /home/joe/
+.fi
+.RE
+.IP
+This makes all files owned by user "joe", limits the groups to those that
+are available to that user, and makes it impossible for the joe user to do
+a timed exploit of the path to induce a change to a file that the joe user
+has no permissions to change.
+.IP
+The following command does a local copy into the "dest/" dir as user "joe"
+(assuming you've installed support/lsh into a dir on your $PATH):
+.RS 4
+.IP
+.nf
+sudo rsync -aive lsh -M--copy-as=joe src/ lh:dest/
+.fi
+.RE
+.IP "\fB\-\-temp-dir=DIR\fP, \fB\-T\fP"
+This option instructs rsync to use DIR as a scratch directory when creating
+temporary copies of the files transferred on the receiving side. The
+default behavior is to create each temporary file in the same directory as
+the associated destination file. Beginning with rsync 3.1.1, the temp-file
+names inside the specified DIR will not be prefixed with an extra dot
+(though they will still have a random suffix added).
+.IP
+This option is most often used when the receiving disk partition does not
+have enough free space to hold a copy of the largest file in the transfer.
+In this case (i.e. when the scratch directory is on a different disk
+partition), rsync will not be able to rename each received temporary file
+over the top of the associated destination file, but instead must copy it
+into place. Rsync does this by copying the file over the top of the
+destination file, which means that the destination file will contain
+truncated data during this copy. If this were not done this way (even if
+the destination file were first removed, the data locally copied to a
+temporary file in the destination directory, and then renamed into place)
+it would be possible for the old file to continue taking up disk space (if
+someone had it open), and thus there might not be enough room to fit the
+new version on the disk at the same time.
+.IP
+If you are using this option for reasons other than a shortage of disk
+space, you may wish to combine it with the \fB\-\-delay-updates\fP
+option, which will ensure that all copied files get put into subdirectories
+in the destination hierarchy, awaiting the end of the transfer. If you
+don't have enough room to duplicate all the arriving files on the
+destination partition, another way to tell rsync that you aren't overly
+concerned about disk space is to use the \fB\-\-partial-dir\fP option
+with a relative path; because this tells rsync that it is OK to stash off a
+copy of a single file in a subdir in the destination hierarchy, rsync will
+use the partial-dir as a staging area to bring over the copied file, and
+then rename it into place from there. (Specifying a \fB\-\-partial-dir\fP
+with an absolute path does not have this side-effect.)
+.IP "\fB\-\-fuzzy\fP, \fB\-y\fP"
+This option tells rsync that it should look for a basis file for any
+destination file that is missing. The current algorithm looks in the same
+directory as the destination file for either a file that has an identical
+size and modified-time, or a similarly-named file. If found, rsync uses
+the fuzzy basis file to try to speed up the transfer.
+.IP
+If the option is repeated, the fuzzy scan will also be done in any matching
+alternate destination directories that are specified via
+\fB\-\-compare-dest\fP, \fB\-\-copy-dest\fP, or \fB\-\-link-dest\fP.
+.IP
+Note that the use of the \fB\-\-delete\fP option might get rid of any
+potential fuzzy-match files, so either use \fB\-\-delete-after\fP or
+specify some filename exclusions if you need to prevent this.
+.IP "\fB\-\-compare-dest=DIR\fP"
+This option instructs rsync to use \fIDIR\fP on the destination machine as an
+additional hierarchy to compare destination files against doing transfers
+(if the files are missing in the destination directory). If a file is
+found in \fIDIR\fP that is identical to the sender's file, the file will NOT be
+transferred to the destination directory. This is useful for creating a
+sparse backup of just files that have changed from an earlier backup. This
+option is typically used to copy into an empty (or newly created)
+directory.
+.IP
+Beginning in version 2.6.4, multiple \fB\-\-compare-dest\fP directories may be
+provided, which will cause rsync to search the list in the order specified
+for an exact match. If a match is found that differs only in attributes, a
+local copy is made and the attributes updated. If a match is not found, a
+basis file from one of the \fIDIRs\fP will be selected to try to speed up the
+transfer.
+.IP
+If \fIDIR\fP is a relative path, it is relative to the destination directory.
+See also \fB\-\-copy-dest\fP and \fB\-\-link-dest\fP.
+.IP
+NOTE: beginning with version 3.1.0, rsync will remove a file from a
+non-empty destination hierarchy if an exact match is found in one of the
+compare-dest hierarchies (making the end result more closely match a fresh
+copy).
+.IP "\fB\-\-copy-dest=DIR\fP"
+This option behaves like \fB\-\-compare-dest\fP, but rsync will also copy
+unchanged files found in \fIDIR\fP to the destination directory using a local
+copy. This is useful for doing transfers to a new destination while
+leaving existing files intact, and then doing a flash-cutover when all
+files have been successfully transferred.
+.IP
+Multiple \fB\-\-copy-dest\fP directories may be provided, which will cause rsync
+to search the list in the order specified for an unchanged file. If a
+match is not found, a basis file from one of the \fIDIRs\fP will be selected to
+try to speed up the transfer.
+.IP
+If \fIDIR\fP is a relative path, it is relative to the destination directory.
+See also \fB\-\-compare-dest\fP and \fB\-\-link-dest\fP.
+.IP "\fB\-\-link-dest=DIR\fP"
+This option behaves like \fB\-\-copy-dest\fP, but unchanged files are
+hard linked from \fIDIR\fP to the destination directory. The files must be
+identical in all preserved attributes (e.g. permissions, possibly
+ownership) in order for the files to be linked together. An example:
+.RS 4
+.IP
+.nf
+rsync -av --link-dest=$PWD/prior_dir host:src_dir/ new_dir/
+.fi
+.RE
+.IP
+If files aren't linking, double-check their attributes. Also check if
+some attributes are getting forced outside of rsync's control, such a mount
+option that squishes root to a single user, or mounts a removable drive
+with generic ownership (such as OS X's "Ignore ownership on this volume"
+option).
+.IP
+Beginning in version 2.6.4, multiple \fB\-\-link-dest\fP directories may be
+provided, which will cause rsync to search the list in the order specified
+for an exact match (there is a limit of 20 such directories). If a match
+is found that differs only in attributes, a local copy is made and the
+attributes updated. If a match is not found, a basis file from one of the
+\fIDIRs\fP will be selected to try to speed up the transfer.
+.IP
+This option works best when copying into an empty destination hierarchy, as
+existing files may get their attributes tweaked, and that can affect
+alternate destination files via hard-links. Also, itemizing of changes can
+get a bit muddled. Note that prior to version 3.1.0, an
+alternate-directory exact match would never be found (nor linked into the
+destination) when a destination file already exists.
+.IP
+Note that if you combine this option with \fB\-\-ignore-times\fP, rsync will not
+link any files together because it only links identical files together as a
+substitute for transferring the file, never as an additional check after
+the file is updated.
+.IP
+If \fIDIR\fP is a relative path, it is relative to the destination directory.
+See also \fB\-\-compare-dest\fP and \fB\-\-copy-dest\fP.
+.IP
+Note that rsync versions prior to 2.6.1 had a bug that could prevent
+\fB\-\-link-dest\fP from working properly for a non-super-user when
+\fB\-\-owner\fP (\fB\-o\fP) was specified (or implied). You can work-around
+this bug by avoiding the \fB\-o\fP option (or using \fB\-\-no-o\fP) when sending to an
+old rsync.
+.IP "\fB\-\-compress\fP, \fB\-z\fP"
+With this option, rsync compresses the file data as it is sent to the
+destination machine, which reduces the amount of data being transmitted\ \-\-
+something that is useful over a slow connection.
+.IP
+Rsync supports multiple compression methods and will choose one for you
+unless you force the choice using the \fB\-\-compress-choice\fP (\fB\-\-zc\fP)
+option.
+.IP
+Run \fBrsync\ \-\-version\fP to see the default compress list compiled into your
+version.
+.IP
+When both sides of the transfer are at least 3.2.0, rsync chooses the first
+algorithm in the client's list of choices that is also in the server's list
+of choices. If no common compress choice is found, rsync exits with
+an error. If the remote rsync is too old to support checksum negotiation,
+its list is assumed to be "zlib".
+.IP
+The default order can be customized by setting the environment variable
+\fBRSYNC_COMPRESS_LIST\fP to a space-separated list of acceptable
+compression names. If the string contains a "\fB&\fP" character, it is
+separated into the "client string & server string", otherwise the same
+string applies to both. If the string (or string portion) contains no
+non-whitespace characters, the default compress list is used. Any unknown
+compression names are discarded from the list, but a list with only invalid
+names results in a failed negotiation.
+.IP
+There are some older rsync versions that were configured to reject a \fB\-z\fP
+option and require the use of \fB\-zz\fP because their compression library was
+not compatible with the default zlib compression method. You can usually
+ignore this weirdness unless the rsync server complains and tells you to
+specify \fB\-zz\fP.
+.IP "\fB\-\-compress-choice=STR\fP, \fB\-\-zc=STR\fP"
+This option can be used to override the automatic negotiation of the
+compression algorithm that occurs when \fB\-\-compress\fP is used. The
+option implies \fB\-\-compress\fP unless "none" was specified, which
+instead implies \fB\-\-no-compress\fP.
+.IP
+The compression options that you may be able to use are:
+.IP
+.RS
+.IP o
+\fBzstd\fP
+.IP o
+\fBlz4\fP
+.IP o
+\fBzlibx\fP
+.IP o
+\fBzlib\fP
+.IP o
+\fBnone\fP
+.RE
+.IP
+Run \fBrsync\ \-\-version\fP to see the default compress list compiled into your
+version (which may differ from the list above).
+.IP
+Note that if you see an error about an option named \fB\-\-old-compress\fP or
+\fB\-\-new-compress\fP, this is rsync trying to send the \fB\-\-compress-choice=zlib\fP
+or \fB\-\-compress-choice=zlibx\fP option in a backward-compatible manner that
+more rsync versions understand. This error indicates that the older rsync
+version on the server will not allow you to force the compression type.
+.IP
+Note that the "zlibx" compression algorithm is just the "zlib" algorithm
+with matched data excluded from the compression stream (to try to make it
+more compatible with an external zlib implementation).
+.IP "\fB\-\-compress-level=NUM\fP, \fB\-\-zl=NUM\fP"
+Explicitly set the compression level to use (see \fB\-\-compress\fP,
+\fB\-z\fP) instead of letting it default. The \fB\-\-compress\fP option is
+implied as long as the level chosen is not a "don't compress" level for the
+compression algorithm that is in effect (e.g. zlib compression treats level
+0 as "off").
+.IP
+The level values vary depending on the checksum in effect. Because rsync
+will negotiate a checksum choice by default (when the remote rsync is new
+enough), it can be good to combine this option with a
+\fB\-\-compress-choice\fP (\fB\-\-zc\fP) option unless you're sure of the
+choice in effect. For example:
+.RS 4
+.IP
+.nf
+rsync -aiv --zc=zstd --zl=22 host:src/ dest/
+.fi
+.RE
+.IP
+For zlib & zlibx compression the valid values are from 1 to 9 with 6 being
+the default. Specifying \fB\-\-zl=0\fP turns compression off, and specifying
+\fB\-\-zl=\-1\fP chooses the default level of 6.
+.IP
+For zstd compression the valid values are from \-131072 to 22 with 3 being
+the default. Specifying 0 chooses the default of 3.
+.IP
+For lz4 compression there are no levels, so the value is always 0.
+.IP
+If you specify a too-large or too-small value, the number is silently
+limited to a valid value. This allows you to specify something like
+\fB\-\-zl=999999999\fP and be assured that you'll end up with the maximum
+compression level no matter what algorithm was chosen.
+.IP
+If you want to know the compression level that is in effect, specify
+\fB\-\-debug=nstr\fP to see the "negotiated string" results. This will
+report something like "\fBClient\ compress:\ zstd\ (level\ 3)\fP" (along with the
+checksum choice in effect).
+.IP "\fB\-\-skip-compress=LIST\fP"
+\fBNOTE:\fP no compression method currently supports per-file compression
+changes, so this option has no effect.
+.IP
+Override the list of file suffixes that will be compressed as little as
+possible. Rsync sets the compression level on a per-file basis based on
+the file's suffix. If the compression algorithm has an "off" level, then
+no compression occurs for those files. Other algorithms that support
+changing the streaming level on-the-fly will have the level minimized to
+reduces the CPU usage as much as possible for a matching file.
+.IP
+The \fBLIST\fP should be one or more file suffixes (without the dot) separated
+by slashes (\fB/\fP). You may specify an empty string to indicate that no files
+should be skipped.
+.IP
+Simple character-class matching is supported: each must consist of a list
+of letters inside the square brackets (e.g. no special classes, such as
+"[:alpha:]", are supported, and '\-' has no special meaning).
+.IP
+The characters asterisk (\fB*\fP) and question-mark (\fB?\fP) have no special meaning.
+.IP
+Here's an example that specifies 6 suffixes to skip (since 1 of the 5 rules
+matches 2 suffixes):
+.RS 4
+.IP
+.nf
+--skip-compress=gz/jpg/mp[34]/7z/bz2
+.fi
+.RE
+.IP
+The default file suffixes in the skip-compress list in this version of
+rsync are:
+.RS 4
+.IP
+3g2
+3gp
+7z
+aac
+ace
+apk
+avi
+bz2
+deb
+dmg
+ear
+f4v
+flac
+flv
+gpg
+gz
+iso
+jar
+jpeg
+jpg
+lrz
+lz
+lz4
+lzma
+lzo
+m1a
+m1v
+m2a
+m2ts
+m2v
+m4a
+m4b
+m4p
+m4r
+m4v
+mka
+mkv
+mov
+mp1
+mp2
+mp3
+mp4
+mpa
+mpeg
+mpg
+mpv
+mts
+odb
+odf
+odg
+odi
+odm
+odp
+ods
+odt
+oga
+ogg
+ogm
+ogv
+ogx
+opus
+otg
+oth
+otp
+ots
+ott
+oxt
+png
+qt
+rar
+rpm
+rz
+rzip
+spx
+squashfs
+sxc
+sxd
+sxg
+sxm
+sxw
+sz
+tbz
+tbz2
+tgz
+tlz
+ts
+txz
+tzo
+vob
+war
+webm
+webp
+xz
+z
+zip
+zst
+.RE
+.IP
+This list will be replaced by your \fB\-\-skip-compress\fP list in all but one
+situation: a copy from a daemon rsync will add your skipped suffixes to its
+list of non-compressing files (and its list may be configured to a
+different default).
+.IP "\fB\-\-numeric-ids\fP"
+With this option rsync will transfer numeric group and user IDs rather than
+using user and group names and mapping them at both ends.
+.IP
+By default rsync will use the username and groupname to determine what
+ownership to give files. The special uid 0 and the special group 0 are
+never mapped via user/group names even if the \fB\-\-numeric-ids\fP option is not
+specified.
+.IP
+If a user or group has no name on the source system or it has no match on
+the destination system, then the numeric ID from the source system is used
+instead. See also the \fBuse\ chroot\fP setting
+in the rsyncd.conf manpage for some comments on how the chroot setting
+affects rsync's ability to look up the names of the users and groups and
+what you can do about it.
+.IP "\fB\-\-usermap=STRING\fP, \fB\-\-groupmap=STRING\fP"
+These options allow you to specify users and groups that should be mapped
+to other values by the receiving side. The \fBSTRING\fP is one or more
+\fBFROM\fP:\fBTO\fP pairs of values separated by commas. Any matching \fBFROM\fP
+value from the sender is replaced with a \fBTO\fP value from the receiver.
+You may specify usernames or user IDs for the \fBFROM\fP and \fBTO\fP values,
+and the \fBFROM\fP value may also be a wild-card string, which will be
+matched against the sender's names (wild-cards do NOT match against ID
+numbers, though see below for why a '\fB*\fP' matches everything). You may
+instead specify a range of ID numbers via an inclusive range: LOW-HIGH.
+For example:
+.RS 4
+.IP
+.nf
+--usermap=0-99:nobody,wayne:admin,*:normal --groupmap=usr:1,1:usr
+.fi
+.RE
+.IP
+The first match in the list is the one that is used. You should specify
+all your user mappings using a single \fB\-\-usermap\fP option, and/or all your
+group mappings using a single \fB\-\-groupmap\fP option.
+.IP
+Note that the sender's name for the 0 user and group are not transmitted to
+the receiver, so you should either match these values using a 0, or use the
+names in effect on the receiving side (typically "root"). All other
+\fBFROM\fP names match those in use on the sending side. All \fBTO\fP names
+match those in use on the receiving side.
+.IP
+Any IDs that do not have a name on the sending side are treated as having
+an empty name for the purpose of matching. This allows them to be matched
+via a "\fB*\fP" or using an empty name. For instance:
+.RS 4
+.IP
+.nf
+--usermap=:nobody --groupmap=*:nobody
+.fi
+.RE
+.IP
+When the \fB\-\-numeric-ids\fP option is used, the sender does not send any
+names, so all the IDs are treated as having an empty name. This means that
+you will need to specify numeric \fBFROM\fP values if you want to map these
+nameless IDs to different values.
+.IP
+For the \fB\-\-usermap\fP option to work, the receiver will need to be running as
+a super-user (see also the \fB\-\-super\fP and \fB\-\-fake-super\fP
+options). For the \fB\-\-groupmap\fP option to work, the receiver will need to
+have permissions to set that group.
+.IP
+Starting with rsync 3.2.4, the \fB\-\-usermap\fP option implies the
+\fB\-\-owner\fP (\fB\-o\fP) option while the \fB\-\-groupmap\fP option implies the
+\fB\-\-group\fP (\fB\-g\fP) option (since rsync needs to have those options
+enabled for the mapping options to work).
+.IP
+An older rsync client may need to use \fB\-s\fP to avoid a complaint
+about wildcard characters, but a modern rsync handles this automatically.
+.IP "\fB\-\-chown=USER:GROUP\fP"
+This option forces all files to be owned by USER with group GROUP. This is
+a simpler interface than using \fB\-\-usermap\fP & \fB\-\-groupmap\fP
+directly, but it is implemented using those options internally so they
+cannot be mixed. If either the USER or GROUP is empty, no mapping for the
+omitted user/group will occur. If GROUP is empty, the trailing colon may
+be omitted, but if USER is empty, a leading colon must be supplied.
+.IP
+If you specify "\fB\-\-chown=foo:bar\fP", this is exactly the same as specifying
+"\fB\-\-usermap=*:foo\ \-\-groupmap=*:bar\fP", only easier (and with the same
+implied \fB\-\-owner\fP and/or \fB\-\-group\fP options).
+.IP
+An older rsync client may need to use \fB\-s\fP to avoid a complaint
+about wildcard characters, but a modern rsync handles this automatically.
+.IP "\fB\-\-timeout=SECONDS\fP"
+This option allows you to set a maximum I/O timeout in seconds. If no data
+is transferred for the specified time then rsync will exit. The default is
+0, which means no timeout.
+.IP "\fB\-\-contimeout=SECONDS\fP"
+This option allows you to set the amount of time that rsync will wait for
+its connection to an rsync daemon to succeed. If the timeout is reached,
+rsync exits with an error.
+.IP "\fB\-\-address=ADDRESS\fP"
+By default rsync will bind to the wildcard address when connecting to an
+rsync daemon. The \fB\-\-address\fP option allows you to specify a specific IP
+address (or hostname) to bind to.
+.IP
+See also the daemon version of the \fB\-\-address\fP option.
+.IP "\fB\-\-port=PORT\fP"
+This specifies an alternate TCP port number to use rather than the default
+of 873. This is only needed if you are using the double-colon (::) syntax
+to connect with an rsync daemon (since the URL syntax has a way to specify
+the port as a part of the URL).
+.IP
+See also the daemon version of the \fB\-\-port\fP option.
+.IP "\fB\-\-sockopts=OPTIONS\fP"
+This option can provide endless fun for people who like to tune their
+systems to the utmost degree. You can set all sorts of socket options
+which may make transfers faster (or slower!). Read the manpage for the
+\fBsetsockopt()\fP system call for details on some of the options you may be
+able to set. By default no special socket options are set. This only
+affects direct socket connections to a remote rsync daemon.
+.IP
+See also the daemon version of the \fB\-\-sockopts\fP option.
+.IP "\fB\-\-blocking-io\fP"
+This tells rsync to use blocking I/O when launching a remote shell
+transport. If the remote shell is either rsh or remsh, rsync defaults to
+using blocking I/O, otherwise it defaults to using non-blocking I/O. (Note
+that ssh prefers non-blocking I/O.)
+.IP "\fB\-\-outbuf=MODE\fP"
+This sets the output buffering mode. The mode can be None (aka
+Unbuffered), Line, or Block (aka Full). You may specify as little as a
+single letter for the mode, and use upper or lower case.
+.IP
+The main use of this option is to change Full buffering to Line buffering
+when rsync's output is going to a file or pipe.
+.IP "\fB\-\-itemize-changes\fP, \fB\-i\fP"
+Requests a simple itemized list of the changes that are being made to each
+file, including attribute changes. This is exactly the same as specifying
+\fB\-\-out-format='%i\ %n%L'\fP. If you repeat the option, unchanged
+files will also be output, but only if the receiving rsync is at least
+version 2.6.7 (you can use \fB\-vv\fP with older versions of rsync, but that
+also turns on the output of other verbose messages).
+.IP
+The "%i" escape has a cryptic output that is 11 letters long. The general
+format is like the string \fBYXcstpoguax\fP, where \fBY\fP is replaced by the type
+of update being done, \fBX\fP is replaced by the file-type, and the other
+letters represent attributes that may be output if they are being modified.
+.IP
+The update types that replace the \fBY\fP are as follows:
+.IP
+.RS
+.IP o
+A \fB<\fP means that a file is being transferred to the remote host (sent).
+.IP o
+A \fB>\fP means that a file is being transferred to the local host
+(received).
+.IP o
+A \fBc\fP means that a local change/creation is occurring for the item (such
+as the creation of a directory or the changing of a symlink, etc.).
+.IP o
+A \fBh\fP means that the item is a hard link to another item (requires
+\fB\-\-hard-links\fP).
+.IP o
+A \fB.\fP means that the item is not being updated (though it might have
+attributes that are being modified).
+.IP o
+A \fB*\fP means that the rest of the itemized-output area contains a message
+(e.g. "deleting").
+.RE
+.IP
+The file-types that replace the \fBX\fP are: \fBf\fP for a file, a \fBd\fP for a
+directory, an \fBL\fP for a symlink, a \fBD\fP for a device, and a \fBS\fP for a
+special file (e.g. named sockets and fifos).
+.IP
+The other letters in the string indicate if some attributes of the file
+have changed, as follows:
+.IP
+.RS
+.IP o
+"\fB.\fP" \- the attribute is unchanged.
+.IP o
+"\fB+\fP" \- the file is newly created.
+.IP o
+"\fB\ \fP" \- all the attributes are unchanged (all dots turn to spaces).
+.IP o
+"\fB?\fP" \- the change is unknown (when the remote rsync is old).
+.IP o
+A letter indicates an attribute is being updated.
+.RE
+.IP
+The attribute that is associated with each letter is as follows:
+.IP
+.RS
+.IP o
+A \fBc\fP means either that a regular file has a different checksum (requires
+\fB\-\-checksum\fP) or that a symlink, device, or special file has a
+changed value. Note that if you are sending files to an rsync prior to
+3.0.1, this change flag will be present only for checksum-differing
+regular files.
+.IP o
+A \fBs\fP means the size of a regular file is different and will be updated
+by the file transfer.
+.IP o
+A \fBt\fP means the modification time is different and is being updated to
+the sender's value (requires \fB\-\-times\fP). An alternate value of
+\fBT\fP means that the modification time will be set to the transfer time,
+which happens when a file/symlink/device is updated without
+\fB\-\-times\fP and when a symlink is changed and the receiver can't
+set its time. (Note: when using an rsync 3.0.0 client, you might see the
+\fBs\fP flag combined with \fBt\fP instead of the proper \fBT\fP flag for this
+time-setting failure.)
+.IP o
+A \fBp\fP means the permissions are different and are being updated to the
+sender's value (requires \fB\-\-perms\fP).
+.IP o
+An \fBo\fP means the owner is different and is being updated to the sender's
+value (requires \fB\-\-owner\fP and super-user privileges).
+.IP o
+A \fBg\fP means the group is different and is being updated to the sender's
+value (requires \fB\-\-group\fP and the authority to set the group).
+.IP o
+.IP
+.RS
+.IP o
+A \fBu\fP|\fBn\fP|\fBb\fP indicates the following information:
+
+\fBu\fP means the access (use) time is different and is being updated to
+the sender's value (requires \fB\-\-atimes\fP)
+.IP o
+\fBn\fP means the create time (newness) is different and is being updated
+to the sender's value (requires \fB\-\-crtimes\fP)
+.IP o
+\fBb\fP means that both the access and create times are being updated
+.RE
+.IP o
+The \fBa\fP means that the ACL information is being changed.
+.IP o
+The \fBx\fP means that the extended attribute information is being changed.
+.RE
+.IP
+One other output is possible: when deleting files, the "%i" will output the
+string "\fB*deleting\fP" for each item that is being removed (assuming that you
+are talking to a recent enough rsync that it logs deletions instead of
+outputting them as a verbose message).
+.IP "\fB\-\-out-format=FORMAT\fP"
+This allows you to specify exactly what the rsync client outputs to the
+user on a per-update basis. The format is a text string containing
+embedded single-character escape sequences prefixed with a percent (%)
+character. A default format of "%n%L" is assumed if either
+\fB\-\-info=name\fP or \fB\-v\fP is specified (this tells you just the
+name of the file and, if the item is a link, where it points). For a full
+list of the possible escape characters, see the \fBlog\ format\fP setting in the rsyncd.conf manpage.
+.IP
+Specifying the \fB\-\-out-format\fP option implies the \fB\-\-info=name\fP
+option, which will mention each file, dir, etc. that gets updated in a
+significant way (a transferred file, a recreated symlink/device, or a
+touched directory). In addition, if the itemize-changes escape (%i) is
+included in the string (e.g. if the \fB\-\-itemize-changes\fP option was
+used), the logging of names increases to mention any item that is changed
+in any way (as long as the receiving side is at least 2.6.4). See the
+\fB\-\-itemize-changes\fP option for a description of the output of "%i".
+.IP
+Rsync will output the out-format string prior to a file's transfer unless
+one of the transfer-statistic escapes is requested, in which case the
+logging is done at the end of the file's transfer. When this late logging
+is in effect and \fB\-\-progress\fP is also specified, rsync will also
+output the name of the file being transferred prior to its progress
+information (followed, of course, by the out-format output).
+.IP "\fB\-\-log-file=FILE\fP"
+This option causes rsync to log what it is doing to a file. This is
+similar to the logging that a daemon does, but can be requested for the
+client side and/or the server side of a non-daemon transfer. If specified
+as a client option, transfer logging will be enabled with a default format
+of "%i %n%L". See the \fB\-\-log-file-format\fP option if you wish to
+override this.
+.IP
+Here's an example command that requests the remote side to log what is
+happening:
+.RS 4
+.IP
+.nf
+rsync -av --remote-option=--log-file=/tmp/rlog src/ dest/
+.fi
+.RE
+.IP
+This is very useful if you need to debug why a connection is closing
+unexpectedly.
+.IP
+See also the daemon version of the \fB\-\-log-file\fP option.
+.IP "\fB\-\-log-file-format=FORMAT\fP"
+This allows you to specify exactly what per-update logging is put into the
+file specified by the \fB\-\-log-file\fP option (which must also be
+specified for this option to have any effect). If you specify an empty
+string, updated files will not be mentioned in the log file. For a list of
+the possible escape characters, see the \fBlog\ format\fP
+setting in the rsyncd.conf manpage.
+.IP
+The default FORMAT used if \fB\-\-log-file\fP is specified and this
+option is not is '%i %n%L'.
+.IP
+See also the daemon version of the \fB\-\-log-file-format\fP
+option.
+.IP "\fB\-\-stats\fP"
+This tells rsync to print a verbose set of statistics on the file transfer,
+allowing you to tell how effective rsync's delta-transfer algorithm is for
+your data. This option is equivalent to \fB\-\-info=stats2\fP if
+combined with 0 or 1 \fB\-v\fP options, or \fB\-\-info=stats3\fP if
+combined with 2 or more \fB\-v\fP options.
+.IP
+The current statistics are as follows:
+.IP
+.RS
+.IP o
+\fBNumber\ of\ files\fP is the count of all "files" (in the generic sense),
+which includes directories, symlinks, etc. The total count will be
+followed by a list of counts by filetype (if the total is non-zero). For
+example: "(reg: 5, dir: 3, link: 2, dev: 1, special: 1)" lists the totals
+for regular files, directories, symlinks, devices, and special files. If
+any of value is 0, it is completely omitted from the list.
+.IP o
+\fBNumber\ of\ created\ files\fP is the count of how many "files" (generic
+sense) were created (as opposed to updated). The total count will be
+followed by a list of counts by filetype (if the total is non-zero).
+.IP o
+\fBNumber\ of\ deleted\ files\fP is the count of how many "files" (generic
+sense) were deleted. The total count will be
+followed by a list of counts by filetype (if the total is non-zero).
+Note that this line is only output if deletions are in effect, and only
+if protocol 31 is being used (the default for rsync 3.1.x).
+.IP o
+\fBNumber\ of\ regular\ files\ transferred\fP is the count of normal files that
+were updated via rsync's delta-transfer algorithm, which does not include
+dirs, symlinks, etc. Note that rsync 3.1.0 added the word "regular" into
+this heading.
+.IP o
+\fBTotal\ file\ size\fP is the total sum of all file sizes in the transfer.
+This does not count any size for directories or special files, but does
+include the size of symlinks.
+.IP o
+\fBTotal\ transferred\ file\ size\fP is the total sum of all files sizes for
+just the transferred files.
+.IP o
+\fBLiteral\ data\fP is how much unmatched file-update data we had to send to
+the receiver for it to recreate the updated files.
+.IP o
+\fBMatched\ data\fP is how much data the receiver got locally when recreating
+the updated files.
+.IP o
+\fBFile\ list\ size\fP is how big the file-list data was when the sender sent
+it to the receiver. This is smaller than the in-memory size for the file
+list due to some compressing of duplicated data when rsync sends the
+list.
+.IP o
+\fBFile\ list\ generation\ time\fP is the number of seconds that the sender
+spent creating the file list. This requires a modern rsync on the
+sending side for this to be present.
+.IP o
+\fBFile\ list\ transfer\ time\fP is the number of seconds that the sender spent
+sending the file list to the receiver.
+.IP o
+\fBTotal\ bytes\ sent\fP is the count of all the bytes that rsync sent from the
+client side to the server side.
+.IP o
+\fBTotal\ bytes\ received\fP is the count of all non-message bytes that rsync
+received by the client side from the server side. "Non-message" bytes
+means that we don't count the bytes for a verbose message that the server
+sent to us, which makes the stats more consistent.
+.RE
+.IP "\fB\-\-8-bit-output\fP, \fB\-8\fP"
+This tells rsync to leave all high-bit characters unescaped in the output
+instead of trying to test them to see if they're valid in the current
+locale and escaping the invalid ones. All control characters (but never
+tabs) are always escaped, regardless of this option's setting.
+.IP
+The escape idiom that started in 2.6.7 is to output a literal backslash
+(\fB\\\fP) and a hash (\fB#\fP), followed by exactly 3 octal digits. For example, a
+newline would output as "\fB\\#012\fP". A literal backslash that is in a
+filename is not escaped unless it is followed by a hash and 3 digits (0-9).
+.IP "\fB\-\-human-readable\fP, \fB\-h\fP"
+Output numbers in a more human-readable format. There are 3 possible levels:
+.RS
+.IP
+.IP 1.
+output numbers with a separator between each set of 3 digits (either a
+comma or a period, depending on if the decimal point is represented by a
+period or a comma).
+.IP 2.
+output numbers in units of 1000 (with a character suffix for larger
+units\ \-\- see below).
+.IP 3.
+output numbers in units of 1024.
+.RE
+.IP
+The default is human-readable level 1. Each \fB\-h\fP option increases the
+level by one. You can take the level down to 0 (to output numbers as pure
+digits) by specifying the \fB\-\-no-human-readable\fP (\fB\-\-no-h\fP) option.
+.IP
+The unit letters that are appended in levels 2 and 3 are: \fBK\fP (kilo), \fBM\fP
+(mega), \fBG\fP (giga), \fBT\fP (tera), or \fBP\fP (peta). For example, a 1234567-byte
+file would output as 1.23M in level-2 (assuming that a period is your local
+decimal point).
+.IP
+Backward compatibility note: versions of rsync prior to 3.1.0 do not
+support human-readable level 1, and they default to level 0. Thus,
+specifying one or two \fB\-h\fP options will behave in a comparable manner in
+old and new versions as long as you didn't specify a \fB\-\-no-h\fP option prior
+to one or more \fB\-h\fP options. See the \fB\-\-list-only\fP option for one
+difference.
+.IP "\fB\-\-partial\fP"
+By default, rsync will delete any partially transferred file if the
+transfer is interrupted. In some circumstances it is more desirable to
+keep partially transferred files. Using the \fB\-\-partial\fP option tells rsync
+to keep the partial file which should make a subsequent transfer of the
+rest of the file much faster.
+.IP "\fB\-\-partial-dir=DIR\fP"
+This option modifies the behavior of the \fB\-\-partial\fP option while
+also implying that it be enabled. This enhanced partial-file method puts
+any partially transferred files into the specified \fIDIR\fP instead of writing
+the partial file out to the destination file. On the next transfer, rsync
+will use a file found in this dir as data to speed up the resumption of the
+transfer and then delete it after it has served its purpose.
+.IP
+Note that if \fB\-\-whole-file\fP is specified (or implied), any
+partial-dir files that are found for a file that is being updated will
+simply be removed (since rsync is sending files without using rsync's
+delta-transfer algorithm).
+.IP
+Rsync will create the \fIDIR\fP if it is missing, but just the last dir\ \-\- not
+the whole path. This makes it easy to use a relative path (such as
+"\fB\-\-partial-dir=.rsync-partial\fP") to have rsync create the
+partial-directory in the destination file's directory when it is needed,
+and then remove it again when the partial file is deleted. Note that this
+directory removal is only done for a relative pathname, as it is expected
+that an absolute path is to a directory that is reserved for partial-dir
+work.
+.IP
+If the partial-dir value is not an absolute path, rsync will add an exclude
+rule at the end of all your existing excludes. This will prevent the
+sending of any partial-dir files that may exist on the sending side, and
+will also prevent the untimely deletion of partial-dir items on the
+receiving side. An example: the above \fB\-\-partial-dir\fP option would add the
+equivalent of this "perishable" exclude at the end of any other filter
+rules: \fB\-f\ '\-p\ .rsync-partial/'\fP
+.IP
+If you are supplying your own exclude rules, you may need to add your own
+exclude/hide/protect rule for the partial-dir because:
+.RS
+.IP
+.IP 1.
+the auto-added rule may be ineffective at the end of your other rules, or
+.IP 2.
+you may wish to override rsync's exclude choice.
+.RE
+.IP
+For instance, if you want to make rsync clean-up any left-over partial-dirs
+that may be lying around, you should specify \fB\-\-delete-after\fP and
+add a "risk" filter rule, e.g. \fB\-f\ 'R\ .rsync-partial/'\fP. Avoid using
+\fB\-\-delete-before\fP or \fB\-\-delete-during\fP unless you don't
+need rsync to use any of the left-over partial-dir data during the current
+run.
+.IP
+IMPORTANT: the \fB\-\-partial-dir\fP should not be writable by other users or it
+is a security risk! E.g. AVOID "/tmp"!
+.IP
+You can also set the partial-dir value the \fBRSYNC_PARTIAL_DIR\fP
+environment variable. Setting this in the environment does not force
+\fB\-\-partial\fP to be enabled, but rather it affects where partial
+files go when \fB\-\-partial\fP is specified. For instance, instead of
+using \fB\-\-partial-dir=.rsync-tmp\fP along with \fB\-\-progress\fP, you could
+set \fBRSYNC_PARTIAL_DIR=.rsync-tmp\fP in your environment and then use
+the \fB\-P\fP option to turn on the use of the .rsync-tmp dir for
+partial transfers. The only times that the \fB\-\-partial\fP option does
+not look for this environment value are:
+.RS
+.IP
+.IP 1.
+when \fB\-\-inplace\fP was specified (since \fB\-\-inplace\fP
+conflicts with \fB\-\-partial-dir\fP), and
+.IP 2.
+when \fB\-\-delay-updates\fP was specified (see below).
+.RE
+.IP
+When a modern rsync resumes the transfer of a file in the partial-dir, that
+partial file is now updated in-place instead of creating yet another
+tmp-file copy (so it maxes out at dest + tmp instead of dest + partial +
+tmp). This requires both ends of the transfer to be at least version
+3.2.0.
+.IP
+For the purposes of the daemon-config's "\fBrefuse\ options\fP" setting,
+\fB\-\-partial-dir\fP does \fInot\fP imply \fB\-\-partial\fP. This is so that a
+refusal of the \fB\-\-partial\fP option can be used to disallow the
+overwriting of destination files with a partial transfer, while still
+allowing the safer idiom provided by \fB\-\-partial-dir\fP.
+.IP "\fB\-\-delay-updates\fP"
+This option puts the temporary file from each updated file into a holding
+directory until the end of the transfer, at which time all the files are
+renamed into place in rapid succession. This attempts to make the updating
+of the files a little more atomic. By default the files are placed into a
+directory named \fB.~tmp~\fP in each file's destination directory, but if
+you've specified the \fB\-\-partial-dir\fP option, that directory will be
+used instead. See the comments in the \fB\-\-partial-dir\fP section for
+a discussion of how this \fB.~tmp~\fP dir will be excluded from the transfer,
+and what you can do if you want rsync to cleanup old \fB.~tmp~\fP dirs that
+might be lying around. Conflicts with \fB\-\-inplace\fP and
+\fB\-\-append\fP.
+.IP
+This option implies \fB\-\-no-inc-recursive\fP since it needs the full
+file list in memory in order to be able to iterate over it at the end.
+.IP
+This option uses more memory on the receiving side (one bit per file
+transferred) and also requires enough free disk space on the receiving side
+to hold an additional copy of all the updated files. Note also that you
+should not use an absolute path to \fB\-\-partial-dir\fP unless:
+.RS
+.IP
+.IP 1.
+there is no chance of any of the files in the transfer having the same
+name (since all the updated files will be put into a single directory if
+the path is absolute), and
+.IP 2.
+there are no mount points in the hierarchy (since the delayed updates
+will fail if they can't be renamed into place).
+.RE
+.IP
+See also the "atomic-rsync" python script in the "support" subdir for an
+update algorithm that is even more atomic (it uses \fB\-\-link-dest\fP
+and a parallel hierarchy of files).
+.IP "\fB\-\-prune-empty-dirs\fP, \fB\-m\fP"
+This option tells the receiving rsync to get rid of empty directories from
+the file-list, including nested directories that have no non-directory
+children. This is useful for avoiding the creation of a bunch of useless
+directories when the sending rsync is recursively scanning a hierarchy of
+files using include/exclude/filter rules.
+.IP
+This option can still leave empty directories on the receiving side if you
+make use of TRANSFER_RULES.
+.IP
+Because the file-list is actually being pruned, this option also affects
+what directories get deleted when a delete is active. However, keep in
+mind that excluded files and directories can prevent existing items from
+being deleted due to an exclude both hiding source files and protecting
+destination files. See the perishable filter-rule option for how to avoid
+this.
+.IP
+You can prevent the pruning of certain empty directories from the file-list
+by using a global "protect" filter. For instance, this option would ensure
+that the directory "emptydir" was kept in the file-list:
+.RS 4
+.IP
+.nf
+--filter 'protect emptydir/'
+.fi
+.RE
+.IP
+Here's an example that copies all .pdf files in a hierarchy, only creating
+the necessary destination directories to hold the .pdf files, and ensures
+that any superfluous files and directories in the destination are removed
+(note the hide filter of non-directories being used instead of an exclude):
+.RS 4
+.IP
+.nf
+rsync -avm --del --include='*.pdf' -f 'hide,! */' src/ dest
+.fi
+.RE
+.IP
+If you didn't want to remove superfluous destination files, the more
+time-honored options of \fB\-\-include='*/'\ \-\-exclude='*'\fP would work
+fine in place of the hide-filter (if that is more natural to you).
+.IP "\fB\-\-progress\fP"
+This option tells rsync to print information showing the progress of the
+transfer. This gives a bored user something to watch. With a modern rsync
+this is the same as specifying \fB\-\-info=flist2,name,progress\fP, but
+any user-supplied settings for those info flags takes precedence (e.g.
+\fB\-\-info=flist0\ \-\-progress\fP).
+.IP
+While rsync is transferring a regular file, it updates a progress line that
+looks like this:
+.RS 4
+.IP
+.nf
+782448 63% 110.64kB/s 0:00:04
+.fi
+.RE
+.IP
+In this example, the receiver has reconstructed 782448 bytes or 63% of the
+sender's file, which is being reconstructed at a rate of 110.64 kilobytes
+per second, and the transfer will finish in 4 seconds if the current rate
+is maintained until the end.
+.IP
+These statistics can be misleading if rsync's delta-transfer algorithm is
+in use. For example, if the sender's file consists of the basis file
+followed by additional data, the reported rate will probably drop
+dramatically when the receiver gets to the literal data, and the transfer
+will probably take much longer to finish than the receiver estimated as it
+was finishing the matched part of the file.
+.IP
+When the file transfer finishes, rsync replaces the progress line with a
+summary line that looks like this:
+.RS 4
+.IP
+.nf
+1,238,099 100% 146.38kB/s 0:00:08 (xfr#5, to-chk=169/396)
+.fi
+.RE
+.IP
+In this example, the file was 1,238,099 bytes long in total, the average
+rate of transfer for the whole file was 146.38 kilobytes per second over
+the 8 seconds that it took to complete, it was the 5th transfer of a
+regular file during the current rsync session, and there are 169 more files
+for the receiver to check (to see if they are up-to-date or not) remaining
+out of the 396 total files in the file-list.
+.IP
+In an incremental recursion scan, rsync won't know the total number of
+files in the file-list until it reaches the ends of the scan, but since it
+starts to transfer files during the scan, it will display a line with the
+text "ir-chk" (for incremental recursion check) instead of "to-chk" until
+the point that it knows the full size of the list, at which point it will
+switch to using "to-chk". Thus, seeing "ir-chk" lets you know that the
+total count of files in the file list is still going to increase (and each
+time it does, the count of files left to check will increase by the number
+of the files added to the list).
+.IP "\fB\-P\fP"
+The \fB\-P\fP option is equivalent to "\fB\-\-partial\fP
+\fB\-\-progress\fP". Its purpose is to make it much easier to specify
+these two options for a long transfer that may be interrupted.
+.IP
+There is also a \fB\-\-info=progress2\fP option that outputs statistics
+based on the whole transfer, rather than individual files. Use this flag
+without outputting a filename (e.g. avoid \fB\-v\fP or specify
+\fB\-\-info=name0\fP) if you want to see how the transfer is doing
+without scrolling the screen with a lot of names. (You don't need to
+specify the \fB\-\-progress\fP option in order to use
+\fB\-\-info=progress2\fP.)
+.IP
+Finally, you can get an instant progress report by sending rsync a signal
+of either SIGINFO or SIGVTALRM. On BSD systems, a SIGINFO is generated by
+typing a Ctrl+T (Linux doesn't currently support a SIGINFO signal). When
+the client-side process receives one of those signals, it sets a flag to
+output a single progress report which is output when the current file
+transfer finishes (so it may take a little time if a big file is being
+handled when the signal arrives). A filename is output (if needed)
+followed by the \fB\-\-info=progress2\fP format of progress info. If you
+don't know which of the 3 rsync processes is the client process, it's OK to
+signal all of them (since the non-client processes ignore the signal).
+.IP
+CAUTION: sending SIGVTALRM to an older rsync (pre-3.2.0) will kill it.
+.IP "\fB\-\-password-file=FILE\fP"
+This option allows you to provide a password for accessing an rsync daemon
+via a file or via standard input if \fBFILE\fP is \fB\-\fP. The file should
+contain just the password on the first line (all other lines are ignored).
+Rsync will exit with an error if \fBFILE\fP is world readable or if a
+root-run rsync command finds a non-root-owned file.
+.IP
+This option does not supply a password to a remote shell transport such as
+ssh; to learn how to do that, consult the remote shell's documentation.
+When accessing an rsync daemon using a remote shell as the transport, this
+option only comes into effect after the remote shell finishes its
+authentication (i.e. if you have also specified a password in the daemon's
+config file).
+.IP "\fB\-\-early-input=FILE\fP"
+This option allows rsync to send up to 5K of data to the "early exec"
+script on its stdin. One possible use of this data is to give the script a
+secret that can be used to mount an encrypted filesystem (which you should
+unmount in the the "post-xfer exec" script).
+.IP
+The daemon must be at least version 3.2.1.
+.IP "\fB\-\-list-only\fP"
+This option will cause the source files to be listed instead of
+transferred. This option is inferred if there is a single source arg and
+no destination specified, so its main uses are:
+.RS
+.IP
+.IP 1.
+to turn a copy command that includes a destination arg into a
+file-listing command, or
+.IP 2.
+to be able to specify more than one source arg. Note: be sure to
+include the destination.
+.RE
+.IP
+CAUTION: keep in mind that a source arg with a wild-card is expanded by the
+shell into multiple args, so it is never safe to try to specify a single
+wild-card arg to try to infer this option. A safe example is:
+.RS 4
+.IP
+.nf
+rsync -av --list-only foo* dest/
+.fi
+.RE
+.IP
+This option always uses an output format that looks similar to this:
+.RS 4
+.IP
+.nf
+drwxrwxr-x 4,096 2022/09/30 12:53:11 support
+-rw-rw-r-- 80 2005/01/11 10:37:37 support/Makefile
+.fi
+.RE
+.IP
+The only option that affects this output style is (as of 3.1.0) the
+\fB\-\-human-readable\fP (\fB\-h\fP) option. The default is to output sizes
+as byte counts with digit separators (in a 14-character-width column).
+Specifying at least one \fB\-h\fP option makes the sizes output with unit
+suffixes. If you want old-style bytecount sizes without digit separators
+(and an 11-character-width column) use \fB\-\-no-h\fP.
+.IP
+Compatibility note: when requesting a remote listing of files from an rsync
+that is version 2.6.3 or older, you may encounter an error if you ask for a
+non-recursive listing. This is because a file listing implies the
+\fB\-\-dirs\fP option w/o \fB\-\-recursive\fP, and older rsyncs don't
+have that option. To avoid this problem, either specify the \fB\-\-no-dirs\fP
+option (if you don't need to expand a directory's content), or turn on
+recursion and exclude the content of subdirectories: \fB\-r\ \-\-exclude='/*/*'\fP.
+.IP "\fB\-\-bwlimit=RATE\fP"
+This option allows you to specify the maximum transfer rate for the data
+sent over the socket, specified in units per second. The RATE value can be
+suffixed with a string to indicate a size multiplier, and may be a
+fractional value (e.g. \fB\-\-bwlimit=1.5m\fP). If no suffix is specified, the
+value will be assumed to be in units of 1024 bytes (as if "K" or "KiB" had
+been appended). See the \fB\-\-max-size\fP option for a description of
+all the available suffixes. A value of 0 specifies no limit.
+.IP
+For backward-compatibility reasons, the rate limit will be rounded to the
+nearest KiB unit, so no rate smaller than 1024 bytes per second is
+possible.
+.IP
+Rsync writes data over the socket in blocks, and this option both limits
+the size of the blocks that rsync writes, and tries to keep the average
+transfer rate at the requested limit. Some burstiness may be seen where
+rsync writes out a block of data and then sleeps to bring the average rate
+into compliance.
+.IP
+Due to the internal buffering of data, the \fB\-\-progress\fP option may
+not be an accurate reflection on how fast the data is being sent. This is
+because some files can show up as being rapidly sent when the data is
+quickly buffered, while other can show up as very slow when the flushing of
+the output buffer occurs. This may be fixed in a future version.
+.IP
+See also the daemon version of the \fB\-\-bwlimit\fP option.
+.IP "\fB\-\-stop-after=MINS\fP, (\fB\-\-time-limit=MINS\fP)"
+This option tells rsync to stop copying when the specified number of
+minutes has elapsed.
+.IP
+For maximal flexibility, rsync does not communicate this option to the
+remote rsync since it is usually enough that one side of the connection
+quits as specified. This allows the option's use even when only one side
+of the connection supports it. You can tell the remote side about the time
+limit using \fB\-\-remote-option\fP (\fB\-M\fP), should the need arise.
+.IP
+The \fB\-\-time-limit\fP version of this option is deprecated.
+.IP "\fB\-\-stop-at=y-m-dTh:m\fP"
+This option tells rsync to stop copying when the specified point in time
+has been reached. The date & time can be fully specified in a numeric
+format of year-month-dayThour:minute (e.g. 2000-12-31T23:59) in the local
+timezone. You may choose to separate the date numbers using slashes
+instead of dashes.
+.IP
+The value can also be abbreviated in a variety of ways, such as specifying
+a 2-digit year and/or leaving off various values. In all cases, the value
+will be taken to be the next possible point in time where the supplied
+information matches. If the value specifies the current time or a past
+time, rsync exits with an error.
+.IP
+For example, "1-30" specifies the next January 30th (at midnight local
+time), "14:00" specifies the next 2 P.M., "1" specifies the next 1st of the
+month at midnight, "31" specifies the next month where we can stop on its
+31st day, and ":59" specifies the next 59th minute after the hour.
+.IP
+For maximal flexibility, rsync does not communicate this option to the
+remote rsync since it is usually enough that one side of the connection
+quits as specified. This allows the option's use even when only one side
+of the connection supports it. You can tell the remote side about the time
+limit using \fB\-\-remote-option\fP (\fB\-M\fP), should the need arise. Do
+keep in mind that the remote host may have a different default timezone
+than your local host.
+.IP "\fB\-\-fsync\fP"
+Cause the receiving side to fsync each finished file. This may slow down
+the transfer, but can help to provide peace of mind when updating critical
+files.
+.IP "\fB\-\-write-batch=FILE\fP"
+Record a file that can later be applied to another identical destination
+with \fB\-\-read-batch\fP. See the "BATCH MODE" section for details, and
+also the \fB\-\-only-write-batch\fP option.
+.IP
+This option overrides the negotiated checksum & compress lists and always
+negotiates a choice based on old-school md5/md4/zlib choices. If you want
+a more modern choice, use the \fB\-\-checksum-choice\fP (\fB\-\-cc\fP) and/or
+\fB\-\-compress-choice\fP (\fB\-\-zc\fP) options.
+.IP "\fB\-\-only-write-batch=FILE\fP"
+Works like \fB\-\-write-batch\fP, except that no updates are made on the
+destination system when creating the batch. This lets you transport the
+changes to the destination system via some other means and then apply the
+changes via \fB\-\-read-batch\fP.
+.IP
+Note that you can feel free to write the batch directly to some portable
+media: if this media fills to capacity before the end of the transfer, you
+can just apply that partial transfer to the destination and repeat the
+whole process to get the rest of the changes (as long as you don't mind a
+partially updated destination system while the multi-update cycle is
+happening).
+.IP
+Also note that you only save bandwidth when pushing changes to a remote
+system because this allows the batched data to be diverted from the sender
+into the batch file without having to flow over the wire to the receiver
+(when pulling, the sender is remote, and thus can't write the batch).
+.IP "\fB\-\-read-batch=FILE\fP"
+Apply all of the changes stored in FILE, a file previously generated by
+\fB\-\-write-batch\fP. If \fIFILE\fP is \fB\-\fP, the batch data will be read
+from standard input. See the "BATCH MODE" section for details.
+.IP "\fB\-\-protocol=NUM\fP"
+Force an older protocol version to be used. This is useful for creating a
+batch file that is compatible with an older version of rsync. For
+instance, if rsync 2.6.4 is being used with the \fB\-\-write-batch\fP
+option, but rsync 2.6.3 is what will be used to run the
+\fB\-\-read-batch\fP option, you should use "\-\-protocol=28" when creating
+the batch file to force the older protocol version to be used in the batch
+file (assuming you can't upgrade the rsync on the reading system).
+.IP "\fB\-\-iconv=CONVERT_SPEC\fP"
+Rsync can convert filenames between character sets using this option.
+Using a CONVERT_SPEC of "." tells rsync to look up the default
+character-set via the locale setting. Alternately, you can fully specify
+what conversion to do by giving a local and a remote charset separated by a
+comma in the order \fB\-\-iconv=LOCAL,REMOTE\fP, e.g. \fB\-\-iconv=utf8,iso88591\fP.
+This order ensures that the option will stay the same whether you're
+pushing or pulling files. Finally, you can specify either \fB\-\-no-iconv\fP or
+a CONVERT_SPEC of "\-" to turn off any conversion. The default setting of
+this option is site-specific, and can also be affected via the
+\fBRSYNC_ICONV\fP environment variable.
+.IP
+For a list of what charset names your local iconv library supports, you can
+run "\fBiconv\ \-\-list\fP".
+.IP
+If you specify the \fB\-\-secluded-args\fP (\fB\-s\fP) option, rsync will
+translate the filenames you specify on the command-line that are being sent
+to the remote host. See also the \fB\-\-files-from\fP option.
+.IP
+Note that rsync does not do any conversion of names in filter files
+(including include/exclude files). It is up to you to ensure that you're
+specifying matching rules that can match on both sides of the transfer.
+For instance, you can specify extra include/exclude rules if there are
+filename differences on the two sides that need to be accounted for.
+.IP
+When you pass an \fB\-\-iconv\fP option to an rsync daemon that allows it, the
+daemon uses the charset specified in its "charset" configuration parameter
+regardless of the remote charset you actually pass. Thus, you may feel
+free to specify just the local charset for a daemon transfer (e.g.
+\fB\-\-iconv=utf8\fP).
+.IP "\fB\-\-ipv4\fP, \fB\-4\fP or \fB\-\-ipv6\fP, \fB\-6\fP"
+Tells rsync to prefer IPv4/IPv6 when creating sockets or running ssh. This
+affects sockets that rsync has direct control over, such as the outgoing
+socket when directly contacting an rsync daemon, as well as the forwarding
+of the \fB\-4\fP or \fB\-6\fP option to ssh when rsync can deduce that ssh is being
+used as the remote shell. For other remote shells you'll need to specify
+the "\fB\-\-rsh\ SHELL\ \-4\fP" option directly (or whatever IPv4/IPv6 hint options
+it uses).
+.IP
+See also the daemon version of these options.
+.IP
+If rsync was compiled without support for IPv6, the \fB\-\-ipv6\fP option will
+have no effect. The \fBrsync\ \-\-version\fP output will contain "\fBno\ IPv6\fP" if
+is the case.
+.IP "\fB\-\-checksum-seed=NUM\fP"
+Set the checksum seed to the integer NUM. This 4 byte checksum seed is
+included in each block and MD4 file checksum calculation (the more modern
+MD5 file checksums don't use a seed). By default the checksum seed is
+generated by the server and defaults to the current \fBtime\fP(). This
+option is used to set a specific checksum seed, which is useful for
+applications that want repeatable block checksums, or in the case where the
+user wants a more random checksum seed. Setting NUM to 0 causes rsync to
+use the default of \fBtime\fP() for checksum seed.
+.P
+.SH "DAEMON OPTIONS"
+.P
+The options allowed when starting an rsync daemon are as follows:
+.P
+.IP "\fB\-\-daemon\fP"
+This tells rsync that it is to run as a daemon. The daemon you start
+running may be accessed using an rsync client using the \fBhost::module\fP or
+\fBrsync://host/module/\fP syntax.
+.IP
+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.
+.IP
+See the \fBrsyncd.conf\fP(5) manpage for more details.
+.IP "\fB\-\-address=ADDRESS\fP"
+By default rsync will bind to the wildcard address when run as a daemon
+with the \fB\-\-daemon\fP option. The \fB\-\-address\fP option allows you to specify a
+specific IP address (or hostname) to bind to. This makes virtual hosting
+possible in conjunction with the \fB\-\-config\fP option.
+.IP
+See also the address global option in the
+rsyncd.conf manpage and the client version of the \fB\-\-address\fP
+option.
+.IP "\fB\-\-bwlimit=RATE\fP"
+This option allows you to specify the maximum transfer rate for the data
+the daemon sends over the socket. The client can still specify a smaller
+\fB\-\-bwlimit\fP value, but no larger value will be allowed.
+.IP
+See the client version of the \fB\-\-bwlimit\fP option for some
+extra details.
+.IP "\fB\-\-config=FILE\fP"
+This specifies an alternate config file than the default. This is only
+relevant when \fB\-\-daemon\fP is specified. The default is
+/etc/rsyncd.conf unless the daemon is running over a remote shell program
+and the remote user is not the super-user; in that case the default is
+rsyncd.conf in the current directory (typically $HOME).
+.IP "\fB\-\-dparam=OVERRIDE\fP, \fB\-M\fP"
+This option can be used to set a daemon-config parameter when starting up
+rsync in daemon mode. It is equivalent to adding the parameter at the end
+of the global settings prior to the first module's definition. The
+parameter names can be specified without spaces, if you so desire. For
+instance:
+.RS 4
+.IP
+.nf
+rsync --daemon -M pidfile=/path/rsync.pid
+.fi
+.RE
+.IP "\fB\-\-no-detach\fP"
+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 \fBdaemontools\fP or AIX's \fBSystem\ Resource\ Controller\fP.
+\fB\-\-no-detach\fP is also recommended when rsync is run under a debugger. This
+option has no effect if rsync is run from inetd or sshd.
+.IP "\fB\-\-port=PORT\fP"
+This specifies an alternate TCP port number for the daemon to listen on
+rather than the default of 873.
+.IP
+See also the client version of the \fB\-\-port\fP option and the
+port global setting in the rsyncd.conf manpage.
+.IP "\fB\-\-log-file=FILE\fP"
+This option tells the rsync daemon to use the given log-file name instead
+of using the "\fBlog\ file\fP" setting in the config file.
+.IP
+See also the client version of the \fB\-\-log-file\fP option.
+.IP "\fB\-\-log-file-format=FORMAT\fP"
+This option tells the rsync daemon to use the given FORMAT string instead
+of using the "\fBlog\ format\fP" setting in the config file. It also enables
+"\fBtransfer\ logging\fP" unless the string is empty, in which case transfer
+logging is turned off.
+.IP
+See also the client version of the \fB\-\-log-file-format\fP
+option.
+.IP "\fB\-\-sockopts\fP"
+This overrides the \fBsocket\ options\fP
+setting in the rsyncd.conf file and has the same syntax.
+.IP
+See also the client version of the \fB\-\-sockopts\fP option.
+.IP "\fB\-\-verbose\fP, \fB\-v\fP"
+This option increases the amount of information the daemon logs during its
+startup phase. After the client connects, the daemon's verbosity level
+will be controlled by the options that the client used and the
+"\fBmax\ verbosity\fP" setting in the module's config section.
+.IP
+See also the client version of the \fB\-\-verbose\fP option.
+.IP "\fB\-\-ipv4\fP, \fB\-4\fP or \fB\-\-ipv6\fP, \fB\-6\fP"
+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 \fB\-\-ipv6\fP or \fB\-\-ipv4\fP when starting the
+daemon).
+.IP
+See also the client version of these options.
+.IP
+If rsync was compiled without support for IPv6, the \fB\-\-ipv6\fP option will
+have no effect. The \fBrsync\ \-\-version\fP output will contain "\fBno\ IPv6\fP" if
+is the case.
+.IP "\fB\-\-help\fP, \fB\-h\fP"
+When specified after \fB\-\-daemon\fP, print a short help page describing the
+options available for starting an rsync daemon.
+.P
+.SH "FILTER RULES"
+.P
+The filter rules allow for custom control of several aspects of how files are
+handled:
+.P
+.IP o
+Control which files the sending side puts into the file list that describes
+the transfer hierarchy
+.IP o
+Control which files the receiving side protects from deletion when the file
+is not in the sender's file list
+.IP o
+Control which extended attribute names are skipped when copying xattrs
+.P
+The rules are either directly specified via option arguments or they can be
+read in from one or more files. The filter-rule files can even be a part of
+the hierarchy of files being copied, affecting different parts of the tree in
+different ways.
+.P
+.SS "SIMPLE INCLUDE/EXCLUDE RULES"
+.P
+We will first cover the basics of how include & exclude rules affect what files
+are transferred, ignoring any deletion side-effects. Filter rules mainly
+affect the contents of directories that rsync is "recursing" into, but they can
+also affect a top-level item in the transfer that was specified as a argument.
+.P
+The default for any unmatched file/dir is for it to be included in the
+transfer, which puts the file/dir into the sender's file list. The use of an
+exclude rule causes one or more matching files/dirs to be left out of the
+sender's file list. An include rule can be used to limit the effect of an
+exclude rule that is matching too many files.
+.P
+The order of the rules is important because the first rule that matches is the
+one that takes effect. Thus, if an early rule excludes a file, no include rule
+that comes after it can have any effect. This means that you must place any
+include overrides somewhere prior to the exclude that it is intended to limit.
+.P
+When a directory is excluded, all its contents and sub-contents are also
+excluded. The sender doesn't scan through any of it at all, which can save a
+lot of time when skipping large unneeded sub-trees.
+.P
+It is also important to understand that the include/exclude rules are applied
+to every file and directory that the sender is recursing into. Thus, if you
+want a particular deep file to be included, you have to make sure that none of
+the directories that must be traversed on the way down to that file are
+excluded or else the file will never be discovered to be included. As an
+example, if the directory "\fBa/path\fP" was given as a transfer argument and you
+want to ensure that the file "\fBa/path/down/deep/wanted.txt\fP" is a part of the
+transfer, then the sender must not exclude the directories "\fBa/path\fP",
+"\fBa/path/down\fP", or "\fBa/path/down/deep\fP" as it makes it way scanning through
+the file tree.
+.P
+When you are working on the rules, it can be helpful to ask rsync to tell you
+what is being excluded/included and why. Specifying \fB\-\-debug=FILTER\fP or (when
+pulling files) \fB\-M\-\-debug=FILTER\fP turns on level 1 of the FILTER debug
+information that will output a message any time that a file or directory is
+included or excluded and which rule it matched. Beginning in 3.2.4 it will
+also warn if a filter rule has trailing whitespace, since an exclude of "foo\ "
+(with a trailing space) will not exclude a file named "foo".
+.P
+Exclude and include rules can specify wildcard PATTERN MATCHING RULES
+(similar to shell wildcards) that allow you to match things like a file suffix
+or a portion of a filename.
+.P
+A rule can be limited to only affecting a directory by putting a trailing slash
+onto the filename.
+.P
+.SS "SIMPLE INCLUDE/EXCLUDE EXAMPLE"
+.P
+With the following file tree created on the sending side:
+.RS 4
+.P
+.nf
+mkdir x/
+touch x/file.txt
+mkdir x/y/
+touch x/y/file.txt
+touch x/y/zzz.txt
+mkdir x/z/
+touch x/z/file.txt
+.fi
+.RE
+.P
+Then the following rsync command will transfer the file "\fBx/y/file.txt\fP" and
+the directories needed to hold it, resulting in the path "\fB/tmp/x/y/file.txt\fP"
+existing on the remote host:
+.RS 4
+.P
+.nf
+rsync -ai -f'+ x/' -f'+ x/y/' -f'+ x/y/file.txt' -f'- *' x host:/tmp/
+.fi
+.RE
+.P
+Aside: this copy could also have been accomplished using the \fB\-R\fP
+option (though the 2 commands behave differently if deletions are enabled):
+.RS 4
+.P
+.nf
+rsync -aiR x/y/file.txt host:/tmp/
+.fi
+.RE
+.P
+The following command does not need an include of the "x" directory because it
+is not a part of the transfer (note the traililng slash). Running this command
+would copy just "\fB/tmp/x/file.txt\fP" because the "y" and "z" dirs get excluded:
+.RS 4
+.P
+.nf
+rsync -ai -f'+ file.txt' -f'- *' x/ host:/tmp/x/
+.fi
+.RE
+.P
+This command would omit the zzz.txt file while copying "x" and everything else
+it contains:
+.RS 4
+.P
+.nf
+rsync -ai -f'- zzz.txt' x host:/tmp/
+.fi
+.RE
+.P
+.SS "FILTER RULES WHEN DELETING"
+.P
+By default the include & exclude filter rules affect both the sender
+(as it creates its file list)
+and the receiver (as it creates its file lists for calculating deletions). If
+no delete option is in effect, the receiver skips creating the delete-related
+file lists. This two-sided default can be manually overridden so that you are
+only specifying sender rules or receiver rules, as described in the FILTER
+RULES IN DEPTH section.
+.P
+When deleting, an exclude protects a file from being removed on the receiving
+side while an include overrides that protection (putting the file at risk of
+deletion). The default is for a file to be at risk\ \-\- its safety depends on it
+matching a corresponding file from the sender.
+.P
+An example of the two-sided exclude effect can be illustrated by the copying of
+a C development directory between 2 systems. When doing a touch-up copy, you
+might want to skip copying the built executable and the \fB.o\fP files (sender
+hide) so that the receiving side can build their own and not lose any object
+files that are already correct (receiver protect). For instance:
+.RS 4
+.P
+.nf
+rsync -ai --del -f'- *.o' -f'- cmd' src host:/dest/
+.fi
+.RE
+.P
+Note that using \fB\-f'\-p\ *.o'\fP is even better than \fB\-f'\-\ *.o'\fP if there is a
+chance that the directory structure may have changed. The "p" modifier is
+discussed in FILTER RULE MODIFIERS.
+.P
+One final note, if your shell doesn't mind unexpanded wildcards, you could
+simplify the typing of the filter options by using an underscore in place of
+the space and leaving off the quotes. For instance, \fB\-f\ \-_*.o\ \-f\ \-_cmd\fP (and
+similar) could be used instead of the filter options above.
+.P
+.SS "FILTER RULES IN DEPTH"
+.P
+Rsync supports old-style include/exclude rules and new-style filter rules. The
+older rules are specified using \fB\-\-include\fP and \fB\-\-exclude\fP as
+well as the \fB\-\-include-from\fP and \fB\-\-exclude-from\fP. These are
+limited in behavior but they don't require a "\-" or "+" prefix. An old-style
+exclude rule is turned into a "\fB\-\ name\fP" filter rule (with no modifiers) and an
+old-style include rule is turned into a "\fB+\ name\fP" filter rule (with no
+modifiers).
+.P
+Rsync builds an ordered list of filter rules as specified on the command-line
+and/or read-in from files. New style filter rules have the following syntax:
+.RS 4
+.P
+.nf
+RULE [PATTERN_OR_FILENAME]
+RULE,MODIFIERS [PATTERN_OR_FILENAME]
+.fi
+.RE
+.P
+You have your choice of using either short or long RULE names, as described
+below. If you use a short-named rule, the ',' separating the RULE from the
+MODIFIERS is optional. The PATTERN or FILENAME that follows (when present)
+must come after either a single space or an underscore (_). Any additional
+spaces and/or underscores are considered to be a part of the pattern name.
+Here are the available rule prefixes:
+.P
+.IP "\fBexclude,\ '\-'\fP"
+specifies an exclude pattern that (by default) is both a
+\fBhide\fP and a \fBprotect\fP.
+.IP "\fBinclude,\ '+'\fP"
+specifies an include pattern that (by default) is both a
+\fBshow\fP and a \fBrisk\fP.
+.IP "\fBmerge,\ '.'\fP"
+specifies a merge-file on the client side to read for more
+rules.
+.IP "\fBdir-merge,\ ':'\fP"
+specifies a per-directory merge-file. Using this kind of
+filter rule requires that you trust the sending side's filter checking, so
+it has the side-effect mentioned under the \fB\-\-trust-sender\fP option.
+.IP "\fBhide,\ 'H'\fP"
+specifies a pattern for hiding files from the transfer.
+Equivalent to a sender-only exclude, so \fB\-f'H\ foo'\fP could also be specified
+as \fB\-f'\-s\ foo'\fP.
+.IP "\fBshow,\ 'S'\fP"
+files that match the pattern are not hidden. Equivalent to a
+sender-only include, so \fB\-f'S\ foo'\fP could also be specified as \fB\-f'+s\ foo'\fP.
+.IP "\fBprotect,\ 'P'\fP"
+specifies a pattern for protecting files from deletion.
+Equivalent to a receiver-only exclude, so \fB\-f'P\ foo'\fP could also be
+specified as \fB\-f'\-r\ foo'\fP.
+.IP "\fBrisk,\ 'R'\fP"
+files that match the pattern are not protected. Equivalent to a
+receiver-only include, so \fB\-f'R\ foo'\fP could also be specified as \fB\-f'+r\ foo'\fP.
+.IP "\fBclear,\ '!'\fP"
+clears the current include/exclude list (takes no arg)
+.P
+When rules are being read from a file (using merge or dir-merge), empty lines
+are ignored, as are whole-line comments that start with a '\fB#\fP' (filename rules
+that contain a hash character are unaffected).
+.P
+Note also that the \fB\-\-filter\fP, \fB\-\-include\fP, and
+\fB\-\-exclude\fP 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 \fB\-\-filter\fP option, or the \fB\-\-include-from\fP /
+\fB\-\-exclude-from\fP options.
+.P
+.SS "PATTERN MATCHING RULES"
+.P
+Most of the rules mentioned above take an argument that specifies what the rule
+should match. If rsync is recursing through a directory hierarchy, keep in
+mind that each pattern is matched against the name of every directory in the
+descent path as rsync finds the filenames to send.
+.P
+The matching rules for the pattern argument take several forms:
+.P
+.IP o
+If a pattern contains a \fB/\fP (not counting a trailing slash) or a "\fB**\fP"
+(which can match a slash), then the pattern is matched against the full
+pathname, including any leading directories within the transfer. If the
+pattern doesn't contain a (non-trailing) \fB/\fP or a "\fB**\fP", then it is matched
+only against the final component of the filename or pathname. For example,
+\fBfoo\fP means that the final path component must be "foo" while \fBfoo/bar\fP would
+match the last 2 elements of the path (as long as both elements are within
+the transfer).
+.IP o
+A pattern that ends with a \fB/\fP only matches a directory, not a regular file,
+symlink, or device.
+.IP o
+A pattern that starts with a \fB/\fP is anchored to the start of the transfer
+path instead of the end. For example, \fB/foo/**\fP or \fB/foo/bar/**\fP match only
+leading elements in the path. If the rule is read from a per-directory
+filter file, the transfer path being matched will begin at the level of the
+filter file instead of the top of the transfer. 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.
+.P
+Rsync chooses between doing a simple string match and wildcard matching by
+checking if the pattern contains one of these three wildcard characters: '\fB*\fP',
+\&'\fB?\fP', and '\fB[\fP' :
+.P
+.IP o
+a '\fB?\fP' matches any single character except a slash (\fB/\fP).
+.IP o
+a '\fB*\fP' matches zero or more non-slash characters.
+.IP o
+a '\fB**\fP' matches zero or more characters, including slashes.
+.IP o
+a '\fB[\fP' introduces a character class, such as \fB[a-z]\fP or \fB[[:alpha:]]\fP, that
+must match one character.
+.IP o
+a trailing \fB***\fP in the pattern is a shorthand that allows you to match a
+directory and all its contents using a single rule. For example, specifying
+"\fBdir_name/***\fP" will match both the "dir_name" directory (as if "\fBdir_name/\fP"
+had been specified) and everything in the directory (as if "\fBdir_name/**\fP"
+had been specified).
+.IP o
+a backslash can be used to escape a wildcard character, but it is only
+interpreted as an escape character if at least one wildcard character is
+present in the match pattern. For instance, the pattern "\fBfoo\\bar\fP" matches
+that single backslash literally, while the pattern "\fBfoo\\bar*\fP" would need to
+be changed to "\fBfoo\\\\bar*\fP" to avoid the "\fB\\b\fP" becoming just "b".
+.P
+Here are some examples of exclude/include matching:
+.P
+.IP o
+Option \fB\-f'\-\ *.o'\fP would exclude all filenames ending with \fB.o\fP
+.IP o
+Option \fB\-f'\-\ /foo'\fP would exclude a file (or directory) named foo in the
+transfer-root directory
+.IP o
+Option \fB\-f'\-\ foo/'\fP would exclude any directory named foo
+.IP o
+Option \fB\-f'\-\ foo/*/bar'\fP would exclude any file/dir named bar which is at two
+levels below a directory named foo (if foo is in the transfer)
+.IP o
+Option \fB\-f'\-\ /foo/**/bar'\fP would exclude any file/dir named bar that was two
+or more levels below a top-level directory named foo (note that /foo/bar is
+\fBnot\fP excluded by this)
+.IP o
+Options \fB\-f'+\ */'\ \-f'+\ *.c'\ \-f'\-\ *'\fP would include all directories and .c
+source files but nothing else
+.IP o
+Options \fB\-f'+\ foo/'\ \-f'+\ foo/bar.c'\ \-f'\-\ *'\fP would include only the foo
+directory and foo/bar.c (the foo directory must be explicitly included or it
+would be excluded by the "\fB\-\ *\fP")
+.P
+.SS "FILTER RULE MODIFIERS"
+.P
+The following modifiers are accepted after an include (+) or exclude (\-) rule:
+.P
+.IP o
+A \fB/\fP specifies that the include/exclude rule should be matched against the
+absolute pathname of the current item. For example, \fB\-f'\-/\ /etc/passwd'\fP
+would exclude the passwd file any time the transfer was sending files from
+the "/etc" directory, and "\-/ subdir/foo" would always exclude "foo" when it
+is in a dir named "subdir", even if "foo" is at the root of the current
+transfer.
+.IP o
+A \fB!\fP specifies that the include/exclude should take effect if the pattern
+fails to match. For instance, \fB\-f'\-!\ */'\fP would exclude all non-directories.
+.IP o
+A \fBC\fP is used to indicate that all the global CVS-exclude rules should be
+inserted as excludes in place of the "\-C". No arg should follow.
+.IP o
+An \fBs\fP is used to indicate that the rule applies to the sending side. When a
+rule affects the sending side, it affects what files are put into the
+sender's file list. The default is for a rule to affect both sides unless
+\fB\-\-delete-excluded\fP was specified, in which case default rules become
+sender-side only. See also the hide (H) and show (S) rules, which are an
+alternate way to specify sending-side includes/excludes.
+.IP o
+An \fBr\fP is used to indicate that the rule applies to the receiving side. When
+a rule affects the receiving side, it prevents files from being deleted. See
+the \fBs\fP modifier for more info. See also the protect (P) and risk (R) rules,
+which are an alternate way to specify receiver-side includes/excludes.
+.IP o
+A \fBp\fP indicates that a rule is perishable, meaning that it is ignored in
+directories that are being deleted. For instance, the
+\fB\-\-cvs-exclude\fP (\fB\-C\fP) option's default rules that exclude things
+like "CVS" and "\fB*.o\fP" are marked as perishable, and will not prevent a
+directory that was removed on the source from being deleted on the
+destination.
+.IP o
+An \fBx\fP indicates that a rule affects xattr names in xattr copy/delete
+operations (and is thus ignored when matching file/dir names). If no
+xattr-matching rules are specified, a default xattr filtering rule is used
+(see the \fB\-\-xattrs\fP option).
+.P
+.SS "MERGE-FILE FILTER RULES"
+.P
+You can merge whole files into your filter rules by specifying either a merge
+(.) or a dir-merge (:) filter rule (as introduced in the FILTER RULES
+section above).
+.P
+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).
+.P
+Some examples:
+.RS 4
+.P
+.nf
+merge /etc/rsync/default.rules
+\&. /etc/rsync/default.rules
+dir-merge .per-dir-filter
+dir-merge,n- .non-inherited-per-dir-excludes
+:n- .non-inherited-per-dir-excludes
+.fi
+.RE
+.P
+The following modifiers are accepted after a merge or dir-merge rule:
+.P
+.IP o
+A \fB\-\fP specifies that the file should consist of only exclude patterns, with
+no other rule-parsing except for in-file comments.
+.IP o
+A \fB+\fP specifies that the file should consist of only include patterns, with
+no other rule-parsing except for in-file comments.
+.IP o
+A \fBC\fP is a way to specify that the file should be read in a CVS-compatible
+manner. This turns on 'n', 'w', and '\-', but also allows the list-clearing
+token (!) to be specified. If no filename is provided, ".cvsignore" is
+assumed.
+.IP o
+A \fBe\fP will exclude the merge-file name from the transfer; e.g. "dir-merge,e
+\&.rules" is like "dir-merge .rules" and "\- .rules".
+.IP o
+An \fBn\fP specifies that the rules are not inherited by subdirectories.
+.IP o
+A \fBw\fP specifies that the rules are word-split on 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 prefix-parsing wasn't also disabled).
+.IP o
+You may also specify any of the modifiers for the "+" or "\-" rules (above) in
+order to have the rules that are read in from the file default to having that
+modifier set (except for the \fB!\fP modifier, which would not be useful). For
+instance, "merge,\-/ .excl" would treat the contents of .excl as absolute-path
+excludes, while "dir-merge,s .filt" and ":sC" would each make all their
+per-directory rules apply only on the sending side. If the merge rule
+specifies sides to affect (via the \fBs\fP or \fBr\fP modifier or both), then the
+rules in the file must not specify sides (via a modifier or a rule prefix
+such as \fBhide\fP).
+.P
+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 dir-merge rules are grouped together in the spot where the merge-file
+was specified, so it is possible to override dir-merge 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.
+.P
+Another way to prevent a single rule from a dir-merge file 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 dir-merge filter
+file was found.
+.P
+Here's an example filter file which you'd specify via \fB\-\-filter=".\ file":\fP
+.RS 4
+.P
+.nf
+merge /home/user/.global-filter
+- *.gz
+dir-merge .rules
++ *.[ch]
+- *.o
+- foo*
+.fi
+.RE
+.P
+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).
+.P
+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 \fB\-F\fP):
+.RS 4
+.P
+.nf
+--filter=': /.rsync-filter'
+.fi
+.RE
+.P
+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".)
+.P
+Some examples of this pre-scanning for per-directory files:
+.RS 4
+.P
+.nf
+rsync -avF /src/path/ /dest/dir
+rsync -av --filter=': ../../.rsync-filter' /src/path/ /dest/dir
+rsync -av --filter=': .rsync-filter' /src/path/ /dest/dir
+.fi
+.RE
+.P
+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.
+.P
+If you want to include the contents of a ".cvsignore" in your patterns, you
+should use the rule ":C", which creates a dir-merge of the .cvsignore file, but
+parsed in a CVS-compatible manner. You can use this to affect where the
+\fB\-\-cvs-exclude\fP (\fB\-C\fP) option's inclusion of the per-directory
+\&.cvsignore file gets placed into your rules by putting the ":C" wherever you
+like in your filter rules. Without this, rsync would add the dir-merge rule
+for the .cvsignore file at the end of all your other rules (giving it a lower
+priority than your command-line rules). For example:
+.RS 4
+.P
+.nf
+cat <<EOT | rsync -avC --filter='. -' a/ b
++ foo.o
+:C
+- *.old
+EOT
+rsync -avC --include=foo.o -f :C --exclude='*.old' a/ b
+.fi
+.RE
+.P
+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. To affect the other CVS
+exclude rules (i.e. the default list of exclusions, the contents of
+$HOME/.cvsignore, and the value of $CVSIGNORE) you should omit the \fB\-C\fP
+command-line option and instead insert a "\-C" rule into your filter rules; e.g.
+"\fB\-\-filter=\-C\fP".
+.P
+.SS "LIST-CLEARING FILTER RULE"
+.P
+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).
+.P
+.SS "ANCHORING INCLUDE/EXCLUDE PATTERNS"
+.P
+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.
+.P
+Because the matching is relative to the transfer-root, changing the trailing
+slash on a source path or changing your use of the \fB\-\-relative\fP 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.
+.P
+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:
+.RS 4
+.P
+.nf
+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
+.fi
+.RE
+.RS 4
+.P
+.nf
+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
+.fi
+.RE
+.RS 4
+.P
+.nf
+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
+.fi
+.RE
+.RS 4
+.P
+.nf
+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
+.fi
+.RE
+.P
+The easiest way to see what name you should filter is to just look at the
+output when using \fB\-\-verbose\fP and put a / in front of the name (use the
+\fB\-\-dry-run\fP option if you're not yet ready to copy any files).
+.P
+.SS "PER-DIRECTORY RULES AND DELETE"
+.P
+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:
+.RS 4
+.P
+.nf
+rsync -av --filter=': .excl' --exclude=.excl host:src/dir /dest
+rsync -av --filter=':e .excl' host:src/dir /dest
+.fi
+.RE
+.P
+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 \fB\-\-delete-after\fP,
+because this ensures that the receiving side gets all the same exclude rules as
+the sending side before it tries to delete anything:
+.RS 4
+.P
+.nf
+rsync -avF --delete-after host:src/dir /dest
+.fi
+.RE
+.P
+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):
+.RS 4
+.P
+.nf
+rsync -av --filter=': .rules' --filter='. /my/extra.rules'
+ --delete host:src/dir /dest
+.fi
+.RE
+.P
+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.
+.P
+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:
+.RS 4
+.P
+.nf
+rsync -av --filter=':e /.rsync-filter' --delete \\
+ host:src/dir /dest
+rsync -avFF --delete host:src/dir /dest
+.fi
+.RE
+.P
+.SH "TRANSFER RULES"
+.P
+In addition to the FILTER RULES that affect the recursive file scans that
+generate the file list on the sending and (when deleting) receiving sides,
+there are transfer rules. These rules affect which files the generator decides
+need to be transferred without the side effects of an exclude filter rule.
+Transfer rules affect only files and never directories.
+.P
+Because a transfer rule does not affect what goes into the sender's (and
+receiver's) file list, it cannot have any effect on which files get deleted on
+the receiving side. For example, if the file "foo" is present in the sender's
+list but its size is such that it is omitted due to a transfer rule, the
+receiving side does not request the file. However, its presence in the file
+list means that a delete pass will not remove a matching file named "foo" on
+the receiving side. On the other hand, a server-side exclude (hide) of the
+file "foo" leaves the file out of the server's file list, and absent a
+receiver-side exclude (protect) the receiver will remove a matching file named
+"foo" if deletions are requested.
+.P
+Given that the files are still in the sender's file list, the
+\fB\-\-prune-empty-dirs\fP option will not judge a directory as being empty
+even if it contains only files that the transfer rules omitted.
+.P
+Similarly, a transfer rule does not have any extra effect on which files are
+deleted on the receiving side, so setting a maximum file size for the transfer
+does not prevent big files from being deleted.
+.P
+Examples of transfer rules include the default "quick check" algorithm (which
+compares size & modify time), the \fB\-\-update\fP option, the
+\fB\-\-max-size\fP option, the \fB\-\-ignore-non-existing\fP option, and a
+few others.
+.P
+.SH "BATCH MODE"
+.P
+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.
+.P
+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.
+.P
+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.
+.P
+For your convenience, a script file is also created when the write-batch option
+is used: it will be named the same as the batch file with ".sh" appended. This
+script file contains a command-line suitable for updating a destination tree
+using the associated batch file. It can be executed using a Bourne (or
+Bourne-like) shell, optionally passing in an alternate destination tree
+pathname which is then used instead of the original destination path. This is
+useful when the destination tree path on the current host differs from the one
+used to create the batch file.
+.P
+Examples:
+.RS 4
+.P
+.nf
+$ rsync --write-batch=foo -a host:/source/dir/ /adest/dir/
+$ scp foo* remote:
+$ ssh remote ./foo.sh /bdest/dir/
+.fi
+.RE
+.RS 4
+.P
+.nf
+$ rsync --write-batch=foo -a /source/dir/ /adest/dir/
+$ ssh remote rsync --read-batch=- -a /bdest/dir/ <foo
+.fi
+.RE
+.P
+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:
+.P
+.IP o
+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.
+.IP o
+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.
+.IP o
+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
+\fB\-\-read-batch\fP 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 \fB\-\-exclude-from=\-\fP option).
+.P
+Caveats:
+.P
+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 a warning (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 \fB\-I\fP 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.
+.P
+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.
+See also the \fB\-\-protocol\fP option for a way to have the creating rsync
+generate a batch file that an older rsync can understand. (Note that batch
+files changed format in version 2.6.3, so mixing versions older than that with
+newer versions will not work.)
+.P
+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 \fB\-\-write-batch\fP changes to \fB\-\-read-batch\fP,
+\fB\-\-files-from\fP is dropped, and the \fB\-\-filter\fP /
+\fB\-\-include\fP / \fB\-\-exclude\fP options are not needed unless one of
+the \fB\-\-delete\fP options is specified.
+.P
+The code that creates the BATCH.sh file transforms any filter/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 \fB\-\-delete\fP is desired. A normal user
+can ignore this detail and just use the shell script as an easy way to run the
+appropriate \fB\-\-read-batch\fP command for the batched data.
+.P
+The original batch mode in rsync was based on "rsync+", but the latest
+version uses a new implementation.
+.P
+.SH "SYMBOLIC LINKS"
+.P
+Three basic behaviors are possible when rsync encounters a symbolic
+link in the source directory.
+.P
+By default, symbolic links are not transferred at all. A message "skipping
+non-regular" file is emitted for any symlinks that exist.
+.P
+If \fB\-\-links\fP is specified, then symlinks are added to the transfer
+(instead of being noisily ignored), and the default handling is to recreate
+them with the same target on the destination. Note that \fB\-\-archive\fP
+implies \fB\-\-links\fP.
+.P
+If \fB\-\-copy-links\fP is specified, then symlinks are "collapsed" by
+copying their referent, rather than the symlink.
+.P
+Rsync can also distinguish "safe" and "unsafe" symbolic links. An example
+where this might be used is a web site mirror that wishes to ensure that the
+rsync module that is copied does not include symbolic links to \fB/etc/passwd\fP in
+the public section of the site. Using \fB\-\-copy-unsafe-links\fP will cause
+any links to be copied as the file they point to on the destination. Using
+\fB\-\-safe-links\fP will cause unsafe links to be omitted by the receiver.
+(Note that you must specify or imply \fB\-\-links\fP for
+\fB\-\-safe-links\fP to have any effect.)
+.P
+Symbolic links are considered unsafe if they are absolute symlinks (start with
+\fB/\fP), empty, or if they contain enough ".." components to ascend from the top
+of the transfer.
+.P
+Here's a summary of how the symlink options are interpreted. The list is in
+order of precedence, so if your combination of options isn't mentioned, use the
+first line that is a complete subset of your options:
+.P
+.IP "\fB\-\-copy-links\fP"
+Turn all symlinks into normal files and directories
+(leaving no symlinks in the transfer for any other options to affect).
+.IP "\fB\-\-copy-dirlinks\fP"
+Turn just symlinks to directories into real
+directories, leaving all other symlinks to be handled as described below.
+.IP "\fB\-\-links\ \-\-copy-unsafe-links\fP"
+Turn all unsafe symlinks
+into files and create all safe symlinks.
+.IP "\fB\-\-copy-unsafe-links\fP"
+Turn all unsafe symlinks into files, noisily
+skip all safe symlinks.
+.IP "\fB\-\-links\ \-\-safe-links\fP"
+The receiver skips creating
+unsafe symlinks found in the transfer and creates the safe ones.
+.IP "\fB\-\-links\fP"
+Create all symlinks.
+.P
+For the effect of \fB\-\-munge-links\fP, see the discussion in that option's
+section.
+.P
+Note that the \fB\-\-keep-dirlinks\fP option does not effect symlinks in the
+transfer but instead affects how rsync treats a symlink to a directory that
+already exists on the receiving side. See that option's section for a warning.
+.P
+.SH "DIAGNOSTICS"
+.P
+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?".
+.P
+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:
+.RS 4
+.P
+.nf
+ssh remotehost /bin/true > out.dat
+.fi
+.RE
+.P
+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.
+.P
+If you are having trouble debugging filter patterns, then try specifying the
+\fB\-vv\fP option. At this level of verbosity rsync will show why each individual
+file is included or excluded.
+.P
+.SH "EXIT VALUES"
+.P
+.IP o
+\fB0\fP \- Success
+.IP o
+\fB1\fP \- Syntax or usage error
+.IP o
+\fB2\fP \- Protocol incompatibility
+.IP o
+\fB3\fP \- Errors selecting input/output files, dirs
+.IP o
+.P
+.RS
+.IP o
+\fB4\fP \- Requested action not supported. Either:
+
+an attempt was made to manipulate 64-bit files on a platform that cannot support them
+.IP o
+an option was specified that is supported by the client and not by the server
+.RE
+.IP o
+\fB5\fP \- Error starting client-server protocol
+.IP o
+\fB6\fP \- Daemon unable to append to log-file
+.IP o
+\fB10\fP \- Error in socket I/O
+.IP o
+\fB11\fP \- Error in file I/O
+.IP o
+\fB12\fP \- Error in rsync protocol data stream
+.IP o
+\fB13\fP \- Errors with program diagnostics
+.IP o
+\fB14\fP \- Error in IPC code
+.IP o
+\fB20\fP \- Received SIGUSR1 or SIGINT
+.IP o
+\fB21\fP \- Some error returned by \fBwaitpid()\fP
+.IP o
+\fB22\fP \- Error allocating core memory buffers
+.IP o
+\fB23\fP \- Partial transfer due to error
+.IP o
+\fB24\fP \- Partial transfer due to vanished source files
+.IP o
+\fB25\fP \- The \-\-max-delete limit stopped deletions
+.IP o
+\fB30\fP \- Timeout in data send/receive
+.IP o
+\fB35\fP \- Timeout waiting for daemon connection
+.P
+.SH "ENVIRONMENT VARIABLES"
+.P
+.IP "\fBCVSIGNORE\fP"
+The CVSIGNORE environment variable supplements any ignore patterns in
+\&.cvsignore files. See the \fB\-\-cvs-exclude\fP option for more details.
+.IP "\fBRSYNC_ICONV\fP"
+Specify a default \fB\-\-iconv\fP setting using this environment
+variable. First supported in 3.0.0.
+.IP "\fBRSYNC_OLD_ARGS\fP"
+Specify a "1" if you want the \fB\-\-old-args\fP option to be enabled by
+default, a "2" (or more) if you want it to be enabled in the
+repeated-option state, or a "0" to make sure that it is disabled by
+default. When this environment variable is set to a non-zero value, it
+supersedes the \fBRSYNC_PROTECT_ARGS\fP variable.
+.IP
+This variable is ignored if \fB\-\-old-args\fP, \fB\-\-no-old-args\fP, or
+\fB\-\-secluded-args\fP is specified on the command line.
+.IP
+First supported in 3.2.4.
+.IP "\fBRSYNC_PROTECT_ARGS\fP"
+Specify a non-zero numeric value if you want the \fB\-\-secluded-args\fP
+option to be enabled by default, or a zero value to make sure that it is
+disabled by default.
+.IP
+This variable is ignored if \fB\-\-secluded-args\fP, \fB\-\-no-secluded-args\fP,
+or \fB\-\-old-args\fP is specified on the command line.
+.IP
+First supported in 3.1.0. Starting in 3.2.4, this variable is ignored if
+\fBRSYNC_OLD_ARGS\fP is set to a non-zero value.
+.IP "\fBRSYNC_RSH\fP"
+This 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 \fB\-\-rsh\fP (\fB\-e\fP) option.
+.IP "\fBRSYNC_PROXY\fP"
+This environment variable allows you to redirect your rsync
+client to use a web proxy when connecting to an rsync daemon. You should
+set \fBRSYNC_PROXY\fP to a hostname:port pair.
+.IP "\fBRSYNC_PASSWORD\fP"
+This environment variable allows you to set the password for an rsync
+\fBdaemon\fP connection, which avoids the password prompt. Note that this
+does \fBnot\fP supply a password to a remote shell transport such as ssh
+(consult its documentation for how to do that).
+.IP "\fBUSER\fP or \fBLOGNAME\fP"
+The USER or LOGNAME environment variables are used to determine the default
+username sent to an rsync daemon. If neither is set, the username defaults
+to "nobody". If both are set, \fBUSER\fP takes precedence.
+.IP "\fBRSYNC_PARTIAL_DIR\fP"
+This environment variable specifies the directory to use for a
+\fB\-\-partial\fP transfer without implying that partial transfers be
+enabled. See the \fB\-\-partial-dir\fP option for full details.
+.IP "\fBRSYNC_COMPRESS_LIST\fP"
+This environment variable allows you to customize the negotiation of the
+compression algorithm by specifying an alternate order or a reduced list of
+names. Use the command \fBrsync\ \-\-version\fP to see the available compression
+names. See the \fB\-\-compress\fP option for full details.
+.IP "\fBRSYNC_CHECKSUM_LIST\fP"
+This environment variable allows you to customize the negotiation of the
+checksum algorithm by specifying an alternate order or a reduced list of
+names. Use the command \fBrsync\ \-\-version\fP to see the available checksum
+names. See the \fB\-\-checksum-choice\fP option for full details.
+.IP "\fBRSYNC_MAX_ALLOC\fP"
+This environment variable sets an allocation maximum as if you had used the
+\fB\-\-max-alloc\fP option.
+.IP "\fBRSYNC_PORT\fP"
+This environment variable is not read by rsync, but is instead set in
+its sub-environment when rsync is running the remote shell in combination
+with a daemon connection. This allows a script such as
+\fBrsync-ssl\fP to be able to know the port number that the user
+specified on the command line.
+.IP "\fBHOME\fP"
+This environment variable is used to find the user's default .cvsignore
+file.
+.IP "\fBRSYNC_CONNECT_PROG\fP"
+This environment variable is mainly used in debug setups to set the program
+to use when making a daemon connection. See CONNECTING TO AN RSYNC
+DAEMON for full details.
+.IP "\fBRSYNC_SHELL\fP"
+This environment variable is mainly used in debug setups to set the program
+to use to run the program specified by \fBRSYNC_CONNECT_PROG\fP. See
+CONNECTING TO AN RSYNC DAEMON for full details.
+.P
+.SH "FILES"
+.P
+/etc/rsyncd.conf or rsyncd.conf
+.P
+.SH "SEE ALSO"
+.P
+\fBrsync-ssl\fP(1), \fBrsyncd.conf\fP(5), \fBrrsync\fP(1)
+.P
+.SH "BUGS"
+.P
+.IP o
+Times are transferred as *nix time_t values.
+.IP o
+When transferring to FAT filesystems rsync may re-sync unmodified files. See
+the comments on the \fB\-\-modify-window\fP option.
+.IP o
+File permissions, devices, etc. are transferred as native numerical values.
+.IP o
+See also the comments on the \fB\-\-delete\fP option.
+.P
+Please report bugs! See the web site at https://rsync.samba.org/.
+.P
+.SH "VERSION"
+.P
+This manpage is current for version 3.2.7 of rsync.
+.P
+.SH "INTERNAL OPTIONS"
+.P
+The options \fB\-\-server\fP and \fB\-\-sender\fP are used internally by rsync, and should
+never be typed by a user under normal circumstances. Some awareness of these
+options may be needed in certain scenarios, such as when setting up a login
+that can only run an rsync command. For instance, the support directory of the
+rsync distribution has an example script named rrsync (for restricted rsync)
+that can be used with a restricted ssh login.
+.P
+.SH "CREDITS"
+.P
+Rsync is distributed under the GNU General Public License. See the file
+COPYING for details.
+.P
+An rsync web site is available at https://rsync.samba.org/. The site
+includes an FAQ-O-Matic which may cover questions unanswered by this manual
+page.
+.P
+The rsync github project is https://github.com/WayneD/rsync.
+.P
+We would be delighted to hear from you if you like this program. Please
+contact the mailing-list at rsync@lists.samba.org.
+.P
+This program uses the excellent zlib compression library written by Jean-loup
+Gailly and Mark Adler.
+.P
+.SH "THANKS"
+.P
+Special thanks go out to: John Van Essen, Matt McCutchen, Wesley W. Terpstra,
+David Dykstra, Jos Backus, Sebastian Krahmer, Martin Pool, and our
+gone-but-not-forgotten compadre, J.W. Schultz.
+.P
+Thanks also to Richard Brent, Brendan Mackay, Bill Waite, Stephen Rothwell and
+David Bell. I've probably missed some people, my apologies if I have.
+.P
+.SH "AUTHOR"
+.P
+Rsync was originally written by Andrew Tridgell and Paul Mackerras. Many
+people have later contributed to it. It is currently maintained by Wayne
+Davison.
+.P
+Mailing lists for support and development are available at
+https://lists.samba.org/.
diff --git a/rsync.1.html b/rsync.1.html
new file mode 100644
index 0000000..453b2cd
--- /dev/null
+++ b/rsync.1.html
@@ -0,0 +1,4511 @@
+<html><head>
+<title>rsync(1) manpage</title>
+<meta charset="UTF-8"/>
+<link href="https://fonts.googleapis.com/css2?family=Roboto&family=Roboto+Mono&display=swap" rel="stylesheet">
+<style>
+body {
+ max-width: 50em;
+ margin: auto;
+}
+body, b, strong, u {
+ font-family: 'Roboto', sans-serif;
+}
+a.tgt { font-face: symbol; font-weight: 400; font-size: 70%; visibility: hidden; text-decoration: none; color: #ddd; padding: 0 4px; border: 0; }
+a.tgt:after { content: '🔗'; }
+a.tgt:hover { color: #444; background-color: #eaeaea; }
+h1:hover > a.tgt, h2:hover > a.tgt, h3:hover > a.tgt, dt:hover > a.tgt { visibility: visible; }
+code {
+ font-family: 'Roboto Mono', monospace;
+ font-weight: bold;
+ white-space: pre;
+}
+pre code {
+ display: block;
+ font-weight: normal;
+}
+blockquote pre code {
+ background: #f1f1f1;
+}
+dd p:first-of-type {
+ margin-block-start: 0em;
+}
+</style>
+</head><body>
+<h2 id="NAME">NAME<a href="#NAME" class="tgt"></a></h2>
+<p>rsync -&#8288; a fast, versatile, remote (and local) file-copying tool</p>
+<h2 id="SYNOPSIS">SYNOPSIS<a href="#SYNOPSIS" class="tgt"></a></h2>
+<pre><code>Local:
+ rsync [OPTION...] SRC... [DEST]
+
+Access via remote shell:
+ Pull:
+ rsync [OPTION...] [USER@]HOST:SRC... [DEST]
+ Push:
+ rsync [OPTION...] SRC... [USER@]HOST:DEST
+
+Access via rsync daemon:
+ Pull:
+ rsync [OPTION...] [USER@]HOST::SRC... [DEST]
+ rsync [OPTION...] rsync://[USER@]HOST[:PORT]/SRC... [DEST]
+ Push:
+ rsync [OPTION...] SRC... [USER@]HOST::DEST
+ rsync [OPTION...] SRC... rsync://[USER@]HOST[:PORT]/DEST)
+</code></pre>
+<p>Usages with just one SRC arg and no DEST arg will list the source files instead
+of copying.</p>
+<p>The online version of this manpage (that includes cross-linking of topics)
+is available at <a href="https://download.samba.org/pub/rsync/rsync.1">https://download.samba.org/pub/rsync/rsync.1</a>.</p>
+<h2 id="DESCRIPTION">DESCRIPTION<a href="#DESCRIPTION" class="tgt"></a></h2>
+<p>Rsync is a fast and extraordinarily versatile file copying tool. It can copy
+locally, to/from another host over any remote shell, or to/from a remote rsync
+daemon. It offers a large number of options that control every aspect of its
+behavior and permit very flexible specification of the set of files to be
+copied. It is famous for its delta-transfer algorithm, which reduces the
+amount of data sent over the network by sending only the differences between
+the source files and the existing files in the destination. Rsync is widely
+used for backups and mirroring and as an improved copy command for everyday
+use.</p>
+<p>Rsync finds files that need to be transferred using a &quot;quick check&quot; algorithm
+(by default) that looks for files that have changed in size or in last-modified
+time. Any changes in the other preserved attributes (as requested by options)
+are made on the destination file directly when the quick check indicates that
+the file's data does not need to be updated.</p>
+<p>Some of the additional features of rsync are:</p>
+<ul>
+<li>support for copying links, devices, owners, groups, and permissions</li>
+<li>exclude and exclude-from options similar to GNU tar</li>
+<li>a CVS exclude mode for ignoring the same files that CVS would ignore</li>
+<li>can use any transparent remote shell, including ssh or rsh</li>
+<li>does not require super-user privileges</li>
+<li>pipelining of file transfers to minimize latency costs</li>
+<li>support for anonymous or authenticated rsync daemons (ideal for mirroring)</li>
+</ul>
+<h2 id="GENERAL">GENERAL<a href="#GENERAL" class="tgt"></a></h2>
+<p>Rsync copies files either to or from a remote host, or locally on the current
+host (it does not support copying files between two remote hosts).</p>
+<p>There are two different ways for rsync to contact a remote system: using a
+remote-shell program as the transport (such as ssh or rsh) or contacting an
+rsync daemon directly via TCP. The remote-shell transport is used whenever the
+source or destination path contains a single colon (:) separator after a host
+specification. Contacting an rsync daemon directly happens when the source or
+destination path contains a double colon (::) separator after a host
+specification, OR when an rsync:// URL is specified (see also the <a href="#USING_RSYNC-DAEMON_FEATURES_VIA_A_REMOTE-SHELL_CONNECTION">USING
+RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTION</a> section for an
+exception to this latter rule).</p>
+<p>As a special case, if a single source arg is specified without a destination,
+the files are listed in an output format similar to &quot;<code>ls -l</code>&quot;.</p>
+<p>As expected, if neither the source or destination path specify a remote host,
+the copy occurs locally (see also the <a href="#opt--list-only"><code>--list-only</code></a> option).</p>
+<p>Rsync refers to the local side as the client and the remote side as the server.
+Don't confuse server with an rsync daemon. A daemon is always a server, but a
+server can be either a daemon or a remote-shell spawned process.</p>
+<h2 id="SETUP">SETUP<a href="#SETUP" class="tgt"></a></h2>
+<p>See the file README.md for installation instructions.</p>
+<p>Once installed, you can use rsync to any machine that you can access via a
+remote shell (as well as some that you can access using the rsync daemon-mode
+protocol). For remote transfers, a modern rsync uses ssh for its
+communications, but it may have been configured to use a different remote shell
+by default, such as rsh or remsh.</p>
+<p>You can also specify any remote shell you like, either by using the <a href="#opt-e"><code>-e</code></a>
+command line option, or by setting the <a href="#RSYNC_RSH"><code>RSYNC_RSH</code></a> environment variable.</p>
+<p>Note that rsync must be installed on both the source and destination machines.</p>
+<h2 id="USAGE">USAGE<a href="#USAGE" class="tgt"></a></h2>
+<p>You use rsync in the same way you use rcp. You must specify a source and a
+destination, one of which may be remote.</p>
+<p>Perhaps the best way to explain the syntax is with some examples:</p>
+<blockquote>
+<pre><code>rsync -t *.c foo:src/
+</code></pre>
+</blockquote>
+<p>This would transfer all files matching the pattern <code>*.c</code> from the current
+directory to the directory src on the machine foo. If any of the files already
+exist on the remote system then the rsync remote-update protocol is used to
+update the file by sending only the differences in the data. Note that the
+expansion of wildcards on the command-line (<code>*.c</code>) into a list of files is
+handled by the shell before it runs rsync and not by rsync itself (exactly the
+same as all other Posix-style programs).</p>
+<blockquote>
+<pre><code>rsync -avz foo:src/bar /data/tmp
+</code></pre>
+</blockquote>
+<p>This would recursively transfer all files from the directory src/bar on the
+machine foo into the /data/tmp/bar directory on the local machine. The files
+are transferred in archive mode, which ensures that symbolic links, devices,
+attributes, permissions, ownerships, etc. are preserved in the transfer.
+Additionally, compression will be used to reduce the size of data portions of
+the transfer.</p>
+<blockquote>
+<pre><code>rsync -avz foo:src/bar/ /data/tmp
+</code></pre>
+</blockquote>
+<p>A trailing slash on the source changes this behavior to avoid creating an
+additional directory level at the destination. You can think of a trailing /
+on a source as meaning &quot;copy the contents of this directory&quot; as opposed to
+&quot;copy the directory by name&quot;, but in both cases the attributes of the
+containing directory are transferred to the containing directory on the
+destination. In other words, each of the following commands copies the files
+in the same way, including their setting of the attributes of /dest/foo:</p>
+<blockquote>
+<pre><code>rsync -av /src/foo /dest
+rsync -av /src/foo/ /dest/foo
+</code></pre>
+</blockquote>
+<p>Note also that host and module references don't require a trailing slash to
+copy the contents of the default directory. For example, both of these copy
+the remote directory's contents into &quot;/dest&quot;:</p>
+<blockquote>
+<pre><code>rsync -av host: /dest
+rsync -av host::module /dest
+</code></pre>
+</blockquote>
+<p>You can also use rsync in local-only mode, where both the source and
+destination don't have a ':' in the name. In this case it behaves like an
+improved copy command.</p>
+<p>Finally, you can list all the (listable) modules available from a particular
+rsync daemon by leaving off the module name:</p>
+<blockquote>
+<pre><code>rsync somehost.mydomain.com::
+</code></pre>
+</blockquote>
+<h2 id="COPYING_TO_A_DIFFERENT_NAME">COPYING TO A DIFFERENT NAME<a href="#COPYING_TO_A_DIFFERENT_NAME" class="tgt"></a></h2>
+<p>When you want to copy a directory to a different name, use a trailing slash on
+the source directory to put the contents of the directory into any destination
+directory you like:</p>
+<blockquote>
+<pre><code>rsync -ai foo/ bar/
+</code></pre>
+</blockquote>
+<p>Rsync also has the ability to customize a destination file's name when copying
+a single item. The rules for this are:</p>
+<ul>
+<li>The transfer list must consist of a single item (either a file or an empty
+directory)</li>
+<li>The final element of the destination path must not exist as a directory</li>
+<li>The destination path must not have been specified with a trailing slash</li>
+</ul>
+<p>Under those circumstances, rsync will set the name of the destination's single
+item to the last element of the destination path. Keep in mind that it is best
+to only use this idiom when copying a file and use the above trailing-slash
+idiom when copying a directory.</p>
+<p>The following example copies the <code>foo.c</code> file as <code>bar.c</code> in the <code>save</code> dir
+(assuming that <code>bar.c</code> isn't a directory):</p>
+<blockquote>
+<pre><code>rsync -ai src/foo.c save/bar.c
+</code></pre>
+</blockquote>
+<p>The single-item copy rule might accidentally bite you if you unknowingly copy a
+single item and specify a destination dir that doesn't exist (without using a
+trailing slash). For example, if <code>src/*.c</code> matches one file and <code>save/dir</code>
+doesn't exist, this will confuse you by naming the destination file <code>save/dir</code>:</p>
+<blockquote>
+<pre><code>rsync -ai src/*.c save/dir
+</code></pre>
+</blockquote>
+<p>To prevent such an accident, either make sure the destination dir exists or
+specify the destination path with a trailing slash:</p>
+<blockquote>
+<pre><code>rsync -ai src/*.c save/dir/
+</code></pre>
+</blockquote>
+<h2 id="SORTED_TRANSFER_ORDER">SORTED TRANSFER ORDER<a href="#SORTED_TRANSFER_ORDER" class="tgt"></a></h2>
+<p>Rsync always sorts the specified filenames into its internal transfer list.
+This handles the merging together of the contents of identically named
+directories, makes it easy to remove duplicate filenames. It can, however,
+confuse someone when the files are transferred in a different order than what
+was given on the command-line.</p>
+<p>If you need a particular file to be transferred prior to another, either
+separate the files into different rsync calls, or consider using
+<a href="#opt--delay-updates"><code>--delay-updates</code></a> (which doesn't affect the sorted transfer order, but
+does make the final file-updating phase happen much more rapidly).</p>
+<h2 id="MULTI-HOST_SECURITY">MULTI-HOST SECURITY<a href="#MULTI-HOST_SECURITY" class="tgt"></a></h2>
+<p>Rsync takes steps to ensure that the file requests that are shared in a
+transfer are protected against various security issues. Most of the potential
+problems arise on the receiving side where rsync takes steps to ensure that the
+list of files being transferred remains within the bounds of what was
+requested.</p>
+<p>Toward this end, rsync 3.1.2 and later have aborted when a file list contains
+an absolute or relative path that tries to escape out of the top of the
+transfer. Also, beginning with version 3.2.5, rsync does two more safety
+checks of the file list to (1) ensure that no extra source arguments were added
+into the transfer other than those that the client requested and (2) ensure
+that the file list obeys the exclude rules that were sent to the sender.</p>
+<p>For those that don't yet have a 3.2.5 client rsync (or those that want to be
+extra careful), it is safest to do a copy into a dedicated destination
+directory for the remote files when you don't trust the remote host. For
+example, instead of doing an rsync copy into your home directory:</p>
+<blockquote>
+<pre><code>rsync -aiv host1:dir1 ~
+</code></pre>
+</blockquote>
+<p>Dedicate a &quot;host1-files&quot; dir to the remote content:</p>
+<blockquote>
+<pre><code>rsync -aiv host1:dir1 ~/host1-files
+</code></pre>
+</blockquote>
+<p>See the <a href="#opt--trust-sender"><code>--trust-sender</code></a> option for additional details.</p>
+<p>CAUTION: it is not particularly safe to use rsync to copy files from a
+case-preserving filesystem to a case-ignoring filesystem. If you must perform
+such a copy, you should either disable symlinks via <code>--no-links</code> or enable the
+munging of symlinks via <a href="#opt--munge-links"><code>--munge-links</code></a> (and make sure you use the
+right local or remote option). This will prevent rsync from doing potentially
+dangerous things if a symlink name overlaps with a file or directory. It does
+not, however, ensure that you get a full copy of all the files (since that may
+not be possible when the names overlap). A potentially better solution is to
+list all the source files and create a safe list of filenames that you pass to
+the <a href="#opt--files-from"><code>--files-from</code></a> option. Any files that conflict in name would need
+to be copied to different destination directories using more than one copy.</p>
+<p>While a copy of a case-ignoring filesystem to a case-ignoring filesystem can
+work out fairly well, if no <code>--delete-during</code> or <code>--delete-before</code> option is
+active, rsync can potentially update an existing file on the receiveing side
+without noticing that the upper-/lower-case of the filename should be changed
+to match the sender.</p>
+<h2 id="ADVANCED_USAGE">ADVANCED USAGE<a href="#ADVANCED_USAGE" class="tgt"></a></h2>
+<p>The syntax for requesting multiple files from a remote host is done by
+specifying additional remote-host args in the same style as the first, or with
+the hostname omitted. For instance, all these work:</p>
+<blockquote>
+<pre><code>rsync -aiv host:file1 :file2 host:file{3,4} /dest/
+rsync -aiv host::modname/file{1,2} host::modname/extra /dest/
+rsync -aiv host::modname/first ::extra-file{1,2} /dest/
+</code></pre>
+</blockquote>
+<p>Note that a daemon connection only supports accessing one module per copy
+command, so if the start of a follow-up path doesn't begin with the
+modname of the first path, it is assumed to be a path in the module (such as
+the extra-file1 &amp; extra-file2 that are grabbed above).</p>
+<p>Really old versions of rsync (2.6.9 and before) only allowed specifying one
+remote-source arg, so some people have instead relied on the remote-shell
+performing space splitting to break up an arg into multiple paths. Such
+unintuitive behavior is no longer supported by default (though you can request
+it, as described below).</p>
+<p>Starting in 3.2.4, filenames are passed to a remote shell in such a way as to
+preserve the characters you give it. Thus, if you ask for a file with spaces
+in the name, that's what the remote rsync looks for:</p>
+<blockquote>
+<pre><code>rsync -aiv host:'a simple file.pdf' /dest/
+</code></pre>
+</blockquote>
+<p>If you use scripts that have been written to manually apply extra quoting to
+the remote rsync args (or to require remote arg splitting), you can ask rsync
+to let your script handle the extra escaping. This is done by either adding
+the <a href="#opt--old-args"><code>--old-args</code></a> option to the rsync runs in the script (which requires
+a new rsync) or exporting <a href="#RSYNC_OLD_ARGS">RSYNC_OLD_ARGS</a>=1 and <a href="#RSYNC_PROTECT_ARGS">RSYNC_PROTECT_ARGS</a>=0
+(which works with old or new rsync versions).</p>
+<h2 id="CONNECTING_TO_AN_RSYNC_DAEMON">CONNECTING TO AN RSYNC DAEMON<a href="#CONNECTING_TO_AN_RSYNC_DAEMON" class="tgt"></a></h2>
+<p>It is also possible to use rsync without a remote shell as the transport. In
+this case you will directly connect to a remote rsync daemon, typically using
+TCP port 873. (This obviously requires the daemon to be running on the remote
+system, so refer to the <a href="#STARTING_AN_RSYNC_DAEMON_TO_ACCEPT_CONNECTIONS">STARTING AN RSYNC DAEMON TO ACCEPT CONNECTIONS</a>
+section below for information on that.)</p>
+<p>Using rsync in this way is the same as using it with a remote shell except
+that:</p>
+<ul>
+<li>Use either double-colon syntax or rsync:// URL syntax instead of the
+single-colon (remote shell) syntax.</li>
+<li>The first element of the &quot;path&quot; is actually a module name.</li>
+<li>Additional remote source args can use an abbreviated syntax that omits the
+hostname and/or the module name, as discussed in <a href="#ADVANCED_USAGE">ADVANCED USAGE</a>.</li>
+<li>The remote daemon may print a &quot;message of the day&quot; when you connect.</li>
+<li>If you specify only the host (with no module or path) then a list of
+accessible modules on the daemon is output.</li>
+<li>If you specify a remote source path but no destination, a listing of the
+matching files on the remote daemon is output.</li>
+<li>The <a href="#opt--rsh"><code>--rsh</code></a> (<code>-e</code>) option must be omitted to avoid changing the
+connection style from using a socket connection to <a href="#USING_RSYNC-DAEMON_FEATURES_VIA_A_REMOTE-SHELL_CONNECTION">USING RSYNC-DAEMON
+FEATURES VIA A REMOTE-SHELL CONNECTION</a>.</li>
+</ul>
+<p>An example that copies all the files in a remote module named &quot;src&quot;:</p>
+<blockquote>
+<pre><code>rsync -av host::src /dest
+</code></pre>
+</blockquote>
+<p>Some modules on the remote daemon may require authentication. If so, you will
+receive a password prompt when you connect. You can avoid the password prompt
+by setting the environment variable <a href="#RSYNC_PASSWORD"><code>RSYNC_PASSWORD</code></a> to the password you
+want to use or using the <a href="#opt--password-file"><code>--password-file</code></a> option. This may be useful
+when scripting rsync.</p>
+<p>WARNING: On some systems environment variables are visible to all users. On
+those systems using <a href="#opt--password-file"><code>--password-file</code></a> is recommended.</p>
+<p>You may establish the connection via a web proxy by setting the environment
+variable <a href="#RSYNC_PROXY"><code>RSYNC_PROXY</code></a> to a hostname:port pair pointing to your web proxy.
+Note that your web proxy's configuration must support proxy connections to port
+873.</p>
+<p>You may also establish a daemon connection using a program as a proxy by
+setting the environment variable <a href="#RSYNC_CONNECT_PROG"><code>RSYNC_CONNECT_PROG</code></a> to the commands you
+wish to run in place of making a direct socket connection. The string may
+contain the escape &quot;%H&quot; to represent the hostname specified in the rsync
+command (so use &quot;%%&quot; if you need a single &quot;%&quot; in your string). For example:</p>
+<blockquote>
+<pre><code>export RSYNC_CONNECT_PROG='ssh proxyhost nc %H 873'
+rsync -av targethost1::module/src/ /dest/
+rsync -av rsync://targethost2/module/src/ /dest/
+</code></pre>
+</blockquote>
+<p>The command specified above uses ssh to run nc (netcat) on a proxyhost, which
+forwards all data to port 873 (the rsync daemon) on the targethost (%H).</p>
+<p>Note also that if the <a href="#RSYNC_SHELL"><code>RSYNC_SHELL</code></a> environment variable is set, that
+program will be used to run the <code>RSYNC_CONNECT_PROG</code> command instead of using
+the default shell of the <strong>system()</strong> call.</p>
+<h2 id="USING_RSYNC-DAEMON_FEATURES_VIA_A_REMOTE-SHELL_CONNECTION">USING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTION<a href="#USING_RSYNC-DAEMON_FEATURES_VIA_A_REMOTE-SHELL_CONNECTION" class="tgt"></a></h2>
+<p>It is sometimes useful to use various features of an rsync daemon (such as
+named modules) without actually allowing any new socket connections into a
+system (other than what is already required to allow remote-shell access).
+Rsync supports connecting to a host using a remote shell and then spawning a
+single-use &quot;daemon&quot; server that expects to read its config file in the home dir
+of the remote user. This can be useful if you want to encrypt a daemon-style
+transfer's data, but since the daemon is started up fresh by the remote user,
+you may not be able to use features such as chroot or change the uid used by
+the daemon. (For another way to encrypt a daemon transfer, consider using ssh
+to tunnel a local port to a remote machine and configure a normal rsync daemon
+on that remote host to only allow connections from &quot;localhost&quot;.)</p>
+<p>From the user's perspective, a daemon transfer via a remote-shell connection
+uses nearly the same command-line syntax as a normal rsync-daemon transfer,
+with the only exception being that you must explicitly set the remote shell
+program on the command-line with the <a href="#opt--rsh"><code>--rsh=COMMAND</code></a> option. (Setting the
+RSYNC_RSH in the environment will not turn on this functionality.) For example:</p>
+<blockquote>
+<pre><code>rsync -av --rsh=ssh host::module /dest
+</code></pre>
+</blockquote>
+<p>If you need to specify a different remote-shell user, keep in mind that the
+user@ prefix in front of the host is specifying the rsync-user value (for a
+module that requires user-based authentication). This means that you must give
+the '-&#8288;l user' option to ssh when specifying the remote-shell, as in this
+example that uses the short version of the <a href="#opt--rsh"><code>--rsh</code></a> option:</p>
+<blockquote>
+<pre><code>rsync -av -e &quot;ssh -l ssh-user&quot; rsync-user@host::module /dest
+</code></pre>
+</blockquote>
+<p>The &quot;ssh-user&quot; will be used at the ssh level; the &quot;rsync-user&quot; will be used to
+log-in to the &quot;module&quot;.</p>
+<p>In this setup, the daemon is started by the ssh command that is accessing the
+system (which can be forced via the <code>~/.ssh/authorized_keys</code> file, if desired).
+However, when accessing a daemon directly, it needs to be started beforehand.</p>
+<h2 id="STARTING_AN_RSYNC_DAEMON_TO_ACCEPT_CONNECTIONS">STARTING AN RSYNC DAEMON TO ACCEPT CONNECTIONS<a href="#STARTING_AN_RSYNC_DAEMON_TO_ACCEPT_CONNECTIONS" class="tgt"></a></h2>
+<p>In order to connect to an rsync daemon, the remote system needs to have a
+daemon already running (or it needs to have configured something like inetd to
+spawn an rsync daemon for incoming connections on a particular port). For full
+information on how to start a daemon that will handling incoming socket
+connections, see the <a href="rsyncd.conf.5"><strong>rsyncd.conf</strong>(5)</a> manpage&nbsp;-&#8288;-&#8288; that is
+the config file for the daemon, and it contains the full details for how to run
+the daemon (including stand-alone and inetd configurations).</p>
+<p>If you're using one of the remote-shell transports for the transfer, there is
+no need to manually start an rsync daemon.</p>
+<h2 id="EXAMPLES">EXAMPLES<a href="#EXAMPLES" class="tgt"></a></h2>
+<p>Here are some examples of how rsync can be used.</p>
+<p>To backup a home directory, which consists of large MS Word files and mail
+folders, a per-user cron job can be used that runs this each day:</p>
+<blockquote>
+<pre><code>rsync -aiz . bkhost:backup/joe/
+</code></pre>
+</blockquote>
+<p>To move some files from a remote host to the local host, you could run:</p>
+<blockquote>
+<pre><code>rsync -aiv --remove-source-files rhost:/tmp/{file1,file2}.c ~/src/
+</code></pre>
+</blockquote>
+<h2 id="OPTION_SUMMARY">OPTION SUMMARY<a href="#OPTION_SUMMARY" class="tgt"></a></h2>
+<p>Here is a short summary of the options available in rsync. Each option also
+has its own detailed description later in this manpage.</p>
+<pre><code>--verbose, -v increase verbosity
+--info=FLAGS fine-grained informational verbosity
+--debug=FLAGS fine-grained debug verbosity
+--stderr=e|a|c change stderr output mode (default: errors)
+--quiet, -q suppress non-error messages
+--no-motd suppress daemon-mode MOTD
+--checksum, -c skip based on checksum, not mod-time &amp; size
+--archive, -a archive mode is -rlptgoD (no -A,-X,-U,-N,-H)
+--no-OPTION turn off an implied OPTION (e.g. --no-D)
+--recursive, -r recurse into directories
+--relative, -R use relative path names
+--no-implied-dirs don't send implied dirs with --relative
+--backup, -b make backups (see --suffix &amp; --backup-dir)
+--backup-dir=DIR make backups into hierarchy based in DIR
+--suffix=SUFFIX backup suffix (default ~ w/o --backup-dir)
+--update, -u skip files that are newer on the receiver
+--inplace update destination files in-place
+--append append data onto shorter files
+--append-verify --append w/old data in file checksum
+--dirs, -d transfer directories without recursing
+--old-dirs, --old-d works like --dirs when talking to old rsync
+--mkpath create destination's missing path components
+--links, -l copy symlinks as symlinks
+--copy-links, -L transform symlink into referent file/dir
+--copy-unsafe-links only &quot;unsafe&quot; symlinks are transformed
+--safe-links ignore symlinks that point outside the tree
+--munge-links munge symlinks to make them safe &amp; unusable
+--copy-dirlinks, -k transform symlink to dir into referent dir
+--keep-dirlinks, -K treat symlinked dir on receiver as dir
+--hard-links, -H preserve hard links
+--perms, -p preserve permissions
+--executability, -E preserve executability
+--chmod=CHMOD affect file and/or directory permissions
+--acls, -A preserve ACLs (implies --perms)
+--xattrs, -X preserve extended attributes
+--owner, -o preserve owner (super-user only)
+--group, -g preserve group
+--devices preserve device files (super-user only)
+--copy-devices copy device contents as a regular file
+--write-devices write to devices as files (implies --inplace)
+--specials preserve special files
+-D same as --devices --specials
+--times, -t preserve modification times
+--atimes, -U preserve access (use) times
+--open-noatime avoid changing the atime on opened files
+--crtimes, -N preserve create times (newness)
+--omit-dir-times, -O omit directories from --times
+--omit-link-times, -J omit symlinks from --times
+--super receiver attempts super-user activities
+--fake-super store/recover privileged attrs using xattrs
+--sparse, -S turn sequences of nulls into sparse blocks
+--preallocate allocate dest files before writing them
+--dry-run, -n perform a trial run with no changes made
+--whole-file, -W copy files whole (w/o delta-xfer algorithm)
+--checksum-choice=STR choose the checksum algorithm (aka --cc)
+--one-file-system, -x don't cross filesystem boundaries
+--block-size=SIZE, -B force a fixed checksum block-size
+--rsh=COMMAND, -e specify the remote shell to use
+--rsync-path=PROGRAM specify the rsync to run on remote machine
+--existing skip creating new files on receiver
+--ignore-existing skip updating files that exist on receiver
+--remove-source-files sender removes synchronized files (non-dir)
+--del an alias for --delete-during
+--delete delete extraneous files from dest dirs
+--delete-before receiver deletes before xfer, not during
+--delete-during receiver deletes during the transfer
+--delete-delay find deletions during, delete after
+--delete-after receiver deletes after transfer, not during
+--delete-excluded also delete excluded files from dest dirs
+--ignore-missing-args ignore missing source args without error
+--delete-missing-args delete missing source args from destination
+--ignore-errors delete even if there are I/O errors
+--force force deletion of dirs even if not empty
+--max-delete=NUM don't delete more than NUM files
+--max-size=SIZE don't transfer any file larger than SIZE
+--min-size=SIZE don't transfer any file smaller than SIZE
+--max-alloc=SIZE change a limit relating to memory alloc
+--partial keep partially transferred files
+--partial-dir=DIR put a partially transferred file into DIR
+--delay-updates put all updated files into place at end
+--prune-empty-dirs, -m prune empty directory chains from file-list
+--numeric-ids don't map uid/gid values by user/group name
+--usermap=STRING custom username mapping
+--groupmap=STRING custom groupname mapping
+--chown=USER:GROUP simple username/groupname mapping
+--timeout=SECONDS set I/O timeout in seconds
+--contimeout=SECONDS set daemon connection timeout in seconds
+--ignore-times, -I don't skip files that match size and time
+--size-only skip files that match in size
+--modify-window=NUM, -@ set the accuracy for mod-time comparisons
+--temp-dir=DIR, -T create temporary files in directory DIR
+--fuzzy, -y find similar file for basis if no dest file
+--compare-dest=DIR also compare destination files relative to DIR
+--copy-dest=DIR ... and include copies of unchanged files
+--link-dest=DIR hardlink to files in DIR when unchanged
+--compress, -z compress file data during the transfer
+--compress-choice=STR choose the compression algorithm (aka --zc)
+--compress-level=NUM explicitly set compression level (aka --zl)
+--skip-compress=LIST skip compressing files with suffix in LIST
+--cvs-exclude, -C auto-ignore files in the same way CVS does
+--filter=RULE, -f add a file-filtering RULE
+-F same as --filter='dir-merge /.rsync-filter'
+ repeated: --filter='- .rsync-filter'
+--exclude=PATTERN exclude files matching PATTERN
+--exclude-from=FILE read exclude patterns from FILE
+--include=PATTERN don't exclude files matching PATTERN
+--include-from=FILE read include patterns from FILE
+--files-from=FILE read list of source-file names from FILE
+--from0, -0 all *-from/filter files are delimited by 0s
+--old-args disable the modern arg-protection idiom
+--secluded-args, -s use the protocol to safely send the args
+--trust-sender trust the remote sender's file list
+--copy-as=USER[:GROUP] specify user &amp; optional group for the copy
+--address=ADDRESS bind address for outgoing socket to daemon
+--port=PORT specify double-colon alternate port number
+--sockopts=OPTIONS specify custom TCP options
+--blocking-io use blocking I/O for the remote shell
+--outbuf=N|L|B set out buffering to None, Line, or Block
+--stats give some file-transfer stats
+--8-bit-output, -8 leave high-bit chars unescaped in output
+--human-readable, -h output numbers in a human-readable format
+--progress show progress during transfer
+-P same as --partial --progress
+--itemize-changes, -i output a change-summary for all updates
+--remote-option=OPT, -M send OPTION to the remote side only
+--out-format=FORMAT output updates using the specified FORMAT
+--log-file=FILE log what we're doing to the specified FILE
+--log-file-format=FMT log updates using the specified FMT
+--password-file=FILE read daemon-access password from FILE
+--early-input=FILE use FILE for daemon's early exec input
+--list-only list the files instead of copying them
+--bwlimit=RATE limit socket I/O bandwidth
+--stop-after=MINS Stop rsync after MINS minutes have elapsed
+--stop-at=y-m-dTh:m Stop rsync at the specified point in time
+--fsync fsync every written file
+--write-batch=FILE write a batched update to FILE
+--only-write-batch=FILE like --write-batch but w/o updating dest
+--read-batch=FILE read a batched update from FILE
+--protocol=NUM force an older protocol version to be used
+--iconv=CONVERT_SPEC request charset conversion of filenames
+--checksum-seed=NUM set block/file checksum seed (advanced)
+--ipv4, -4 prefer IPv4
+--ipv6, -6 prefer IPv6
+--version, -V print the version + other info and exit
+--help, -h (*) show this help (* -h is help only on its own)
+</code></pre>
+<p>Rsync can also be run as a daemon, in which case the following options are
+accepted:</p>
+<pre><code>--daemon run as an rsync daemon
+--address=ADDRESS bind to the specified address
+--bwlimit=RATE limit socket I/O bandwidth
+--config=FILE specify alternate rsyncd.conf file
+--dparam=OVERRIDE, -M override global daemon config parameter
+--no-detach do not detach from the parent
+--port=PORT listen on alternate port number
+--log-file=FILE override the &quot;log file&quot; setting
+--log-file-format=FMT override the &quot;log format&quot; setting
+--sockopts=OPTIONS specify custom TCP options
+--verbose, -v increase verbosity
+--ipv4, -4 prefer IPv4
+--ipv6, -6 prefer IPv6
+--help, -h show this help (when used with --daemon)
+</code></pre>
+<h2 id="OPTIONS">OPTIONS<a href="#OPTIONS" class="tgt"></a></h2>
+<p>Rsync accepts both long (double-dash + word) and short (single-dash + letter)
+options. The full list of the available options are described below. If an
+option can be specified in more than one way, the choices are comma-separated.
+Some options only have a long variant, not a short.</p>
+<p>If the option takes a parameter, the parameter is only listed after the long
+variant, even though it must also be specified for the short. When specifying
+a parameter, you can either use the form <code>--option=param</code>, <code>--option param</code>,
+<code>-o=param</code>, <code>-o param</code>, or <code>-oparam</code> (the latter choices assume that your
+option has a short variant).</p>
+<p>The parameter may need to be quoted in some manner for it to survive the
+shell's command-line parsing. Also keep in mind that a leading tilde (<code>~</code>) in
+a pathname is substituted by your shell, so make sure that you separate the
+option name from the pathname using a space if you want the local shell to
+expand it.</p>
+<dl>
+
+<dt id="opt--help"><code>--help</code><a href="#opt--help" class="tgt"></a></dt><dd>
+<p>Print a short help page describing the options available in rsync and exit.
+You can also use <code>-h</code> for <code>--help</code> when it is used without any other
+options (since it normally means <a href="#opt--human-readable"><code>--human-readable</code></a>).</p>
+</dd>
+
+<span id="opt-V"></span><dt id="opt--version"><code>--version</code>, <code>-V</code><a href="#opt--version" class="tgt"></a></dt><dd>
+<p>Print the rsync version plus other info and exit. When repeated, the
+information is output is a JSON format that is still fairly readable
+(client side only).</p>
+<p>The output includes a list of compiled-in capabilities, a list of
+optimizations, the default list of checksum algorithms, the default list of
+compression algorithms, the default list of daemon auth digests, a link to
+the rsync web site, and a few other items.</p>
+</dd>
+
+<span id="opt-v"></span><dt id="opt--verbose"><code>--verbose</code>, <code>-v</code><a href="#opt--verbose" class="tgt"></a></dt><dd>
+<p>This option increases the amount of information you are given during the
+transfer. By default, rsync works silently. A single <code>-v</code> will give you
+information about what files are being transferred and a brief summary at
+the end. Two <code>-v</code> options will give you information on what files are
+being skipped and slightly more information at the end. More than two <code>-v</code>
+options should only be used if you are debugging rsync.</p>
+<p>The end-of-run summary tells you the number of bytes sent to the remote
+rsync (which is the receiving side on a local copy), the number of bytes
+received from the remote host, and the average bytes per second of the
+transferred data computed over the entire length of the rsync run. The
+second line shows the total size (in bytes), which is the sum of all the
+file sizes that rsync considered transferring. It also shows a &quot;speedup&quot;
+value, which is a ratio of the total file size divided by the sum of the
+sent and received bytes (which is really just a feel-good bigger-is-better
+number). Note that these byte values can be made more (or less)
+human-readable by using the <a href="#opt--human-readable"><code>--human-readable</code></a> (or
+<code>--no-human-readable</code>) options.</p>
+<p>In a modern rsync, the <code>-v</code> option is equivalent to the setting of groups
+of <a href="#opt--info"><code>--info</code></a> and <a href="#opt--debug"><code>--debug</code></a> options. You can choose to use
+these newer options in addition to, or in place of using <code>--verbose</code>, as
+any fine-grained settings override the implied settings of <code>-v</code>. Both
+<a href="#opt--info"><code>--info</code></a> and <a href="#opt--debug"><code>--debug</code></a> have a way to ask for help that
+tells you exactly what flags are set for each increase in verbosity.</p>
+<p>However, do keep in mind that a daemon's &quot;<code>max verbosity</code>&quot; setting will limit
+how high of a level the various individual flags can be set on the daemon
+side. For instance, if the max is 2, then any info and/or debug flag that
+is set to a higher value than what would be set by <code>-vv</code> will be downgraded
+to the <code>-vv</code> level in the daemon's logging.</p>
+</dd>
+
+<dt id="opt--info"><code>--info=FLAGS</code><a href="#opt--info" class="tgt"></a></dt><dd>
+<p>This option lets you have fine-grained control over the information output
+you want to see. An individual flag name may be followed by a level
+number, with 0 meaning to silence that output, 1 being the default output
+level, and higher numbers increasing the output of that flag (for those
+that support higher levels). Use <code>--info=help</code> to see all the available
+flag names, what they output, and what flag names are added for each
+increase in the verbose level. Some examples:</p>
+<blockquote>
+<pre><code>rsync -a --info=progress2 src/ dest/
+rsync -avv --info=stats2,misc1,flist0 src/ dest/
+</code></pre>
+</blockquote>
+<p>Note that <code>--info=name</code>'s output is affected by the <a href="#opt--out-format"><code>--out-format</code></a>
+and <a href="#opt--itemize-changes"><code>--itemize-changes</code></a> (<code>-i</code>) options. See those options for more
+information on what is output and when.</p>
+<p>This option was added to 3.1.0, so an older rsync on the server side might
+reject your attempts at fine-grained control (if one or more flags needed
+to be send to the server and the server was too old to understand them).
+See also the &quot;<code>max verbosity</code>&quot; caveat above when dealing with a daemon.</p>
+</dd>
+
+<dt id="opt--debug"><code>--debug=FLAGS</code><a href="#opt--debug" class="tgt"></a></dt><dd>
+<p>This option lets you have fine-grained control over the debug output you
+want to see. An individual flag name may be followed by a level number,
+with 0 meaning to silence that output, 1 being the default output level,
+and higher numbers increasing the output of that flag (for those that
+support higher levels). Use <code>--debug=help</code> to see all the available flag
+names, what they output, and what flag names are added for each increase in
+the verbose level. Some examples:</p>
+<blockquote>
+<pre><code>rsync -avvv --debug=none src/ dest/
+rsync -avA --del --debug=del2,acl src/ dest/
+</code></pre>
+</blockquote>
+<p>Note that some debug messages will only be output when the <a href="#opt--stderr"><code>--stderr=all</code></a>
+option is specified, especially those pertaining to I/O and buffer debugging.</p>
+<p>Beginning in 3.2.0, this option is no longer auto-forwarded to the server
+side in order to allow you to specify different debug values for each side
+of the transfer, as well as to specify a new debug option that is only
+present in one of the rsync versions. If you want to duplicate the same
+option on both sides, using brace expansion is an easy way to save you some
+typing. This works in zsh and bash:</p>
+<blockquote>
+<pre><code>rsync -aiv {-M,}--debug=del2 src/ dest/
+</code></pre>
+</blockquote>
+</dd>
+
+<dt id="opt--stderr"><code>--stderr=errors|all|client</code><a href="#opt--stderr" class="tgt"></a></dt><dd>
+<p>This option controls which processes output to stderr and if info messages
+are also changed to stderr. The mode strings can be abbreviated, so feel
+free to use a single letter value. The 3 possible choices are:</p>
+<ul>
+<li>
+<p><code>errors</code> -&#8288; (the default) causes all the rsync processes to send an
+error directly to stderr, even if the process is on the remote side of
+the transfer. Info messages are sent to the client side via the protocol
+stream. If stderr is not available (i.e. when directly connecting with a
+daemon via a socket) errors fall back to being sent via the protocol
+stream.</p>
+</li>
+<li>
+<p><code>all</code> -&#8288; causes all rsync messages (info and error) to get written
+directly to stderr from all (possible) processes. This causes stderr to
+become line-buffered (instead of raw) and eliminates the ability to
+divide up the info and error messages by file handle. For those doing
+debugging or using several levels of verbosity, this option can help to
+avoid clogging up the transfer stream (which should prevent any chance of
+a deadlock bug hanging things up). It also allows <a href="#opt--debug"><code>--debug</code></a> to
+enable some extra I/O related messages.</p>
+</li>
+<li>
+<p><code>client</code> -&#8288; causes all rsync messages to be sent to the client side
+via the protocol stream. One client process outputs all messages, with
+errors on stderr and info messages on stdout. This <strong>was</strong> the default
+in older rsync versions, but can cause error delays when a lot of
+transfer data is ahead of the messages. If you're pushing files to an
+older rsync, you may want to use <code>--stderr=all</code> since that idiom has
+been around for several releases.</p>
+</li>
+</ul>
+<p>This option was added in rsync 3.2.3. This version also began the
+forwarding of a non-default setting to the remote side, though rsync uses
+the backward-compatible options <code>--msgs2stderr</code> and <code>--no-msgs2stderr</code> to
+represent the <code>all</code> and <code>client</code> settings, respectively. A newer rsync
+will continue to accept these older option names to maintain compatibility.</p>
+</dd>
+
+<span id="opt-q"></span><dt id="opt--quiet"><code>--quiet</code>, <code>-q</code><a href="#opt--quiet" class="tgt"></a></dt><dd>
+<p>This option decreases the amount of information you are given during the
+transfer, notably suppressing information messages from the remote server.
+This option is useful when invoking rsync from cron.</p>
+</dd>
+
+<dt id="opt--no-motd"><code>--no-motd</code><a href="#opt--no-motd" class="tgt"></a></dt><dd>
+<p>This option affects the information that is output by the client at the
+start of a daemon transfer. This suppresses the message-of-the-day (MOTD)
+text, but it also affects the list of modules that the daemon sends in
+response to the &quot;rsync host::&quot; request (due to a limitation in the rsync
+protocol), so omit this option if you want to request the list of modules
+from the daemon.</p>
+</dd>
+
+<span id="opt-I"></span><dt id="opt--ignore-times"><code>--ignore-times</code>, <code>-I</code><a href="#opt--ignore-times" class="tgt"></a></dt><dd>
+<p>Normally rsync will skip any files that are already the same size and have
+the same modification timestamp. This option turns off this &quot;quick check&quot;
+behavior, causing all files to be updated.</p>
+<p>This option can be confusing compared to <a href="#opt--ignore-existing"><code>--ignore-existing</code></a> and
+<a href="#opt--ignore-non-existing"><code>--ignore-non-existing</code></a> in that that they cause rsync to transfer
+fewer files, while this option causes rsync to transfer more files.</p>
+</dd>
+
+<dt id="opt--size-only"><code>--size-only</code><a href="#opt--size-only" class="tgt"></a></dt><dd>
+<p>This modifies rsync's &quot;quick check&quot; algorithm for finding files that need
+to be transferred, changing it from the default of transferring files with
+either a changed size or a changed last-modified time to just looking for
+files that have changed in size. This is useful when starting to use rsync
+after using another mirroring system which may not preserve timestamps
+exactly.</p>
+</dd>
+
+<span id="opt-_"></span><dt id="opt--modify-window"><code>--modify-window=NUM</code>, <code>-@</code><a href="#opt--modify-window" class="tgt"></a></dt><dd>
+<p>When comparing two timestamps, rsync treats the timestamps as being equal
+if they differ by no more than the modify-window value. The default is 0,
+which matches just integer seconds. If you specify a negative value (and
+the receiver is at least version 3.1.3) then nanoseconds will also be taken
+into account. Specifying 1 is useful for copies to/from MS Windows FAT
+filesystems, because FAT represents times with a 2-second resolution
+(allowing times to differ from the original by up to 1 second).</p>
+<p>If you want all your transfers to default to comparing nanoseconds, you can
+create a <code>~/.popt</code> file and put these lines in it:</p>
+<blockquote>
+<pre><code>rsync alias -a -a@-1
+rsync alias -t -t@-1
+</code></pre>
+</blockquote>
+<p>With that as the default, you'd need to specify <code>--modify-window=0</code> (aka
+<code>-@0</code>) to override it and ignore nanoseconds, e.g. if you're copying
+between ext3 and ext4, or if the receiving rsync is older than 3.1.3.</p>
+</dd>
+
+<span id="opt-c"></span><dt id="opt--checksum"><code>--checksum</code>, <code>-c</code><a href="#opt--checksum" class="tgt"></a></dt><dd>
+<p>This changes the way rsync checks if the files have been changed and are in
+need of a transfer. Without this option, rsync uses a &quot;quick check&quot; that
+(by default) checks if each file's size and time of last modification match
+between the sender and receiver. This option changes this to compare a
+128-bit checksum for each file that has a matching size. Generating the
+checksums means that both sides will expend a lot of disk I/O reading all
+the data in the files in the transfer, so this can slow things down
+significantly (and this is prior to any reading that will be done to
+transfer changed files)</p>
+<p>The sending side generates its checksums while it is doing the file-system
+scan that builds the list of the available files. The receiver generates
+its checksums when it is scanning for changed files, and will checksum any
+file that has the same size as the corresponding sender's file: files with
+either a changed size or a changed checksum are selected for transfer.</p>
+<p>Note that rsync always verifies that each <u>transferred</u> file was correctly
+reconstructed on the receiving side by checking a whole-file checksum that
+is generated as the file is transferred, but that automatic
+after-the-transfer verification has nothing to do with this option's
+before-the-transfer &quot;Does this file need to be updated?&quot; check.</p>
+<p>The checksum used is auto-negotiated between the client and the server, but
+can be overridden using either the <a href="#opt--checksum-choice"><code>--checksum-choice</code></a> (<code>--cc</code>)
+option or an environment variable that is discussed in that option's
+section.</p>
+</dd>
+
+<span id="opt-a"></span><dt id="opt--archive"><code>--archive</code>, <code>-a</code><a href="#opt--archive" class="tgt"></a></dt><dd>
+<p>This is equivalent to <code>-rlptgoD</code>. It is a quick way of saying you want
+recursion and want to preserve almost everything. Be aware that it does
+<strong>not</strong> include preserving ACLs (<code>-A</code>), xattrs (<code>-X</code>), atimes (<code>-U</code>),
+crtimes (<code>-N</code>), nor the finding and preserving of hardlinks (<code>-H</code>).</p>
+<p>The only exception to the above equivalence is when <a href="#opt--files-from"><code>--files-from</code></a>
+is specified, in which case <a href="#opt-r"><code>-r</code></a> is not implied.</p>
+</dd>
+
+<dt id="opt--no-OPTION"><code>--no-OPTION</code><a href="#opt--no-OPTION" class="tgt"></a></dt><dd>
+<p>You may turn off one or more implied options by prefixing the option name
+with &quot;no-&quot;. Not all positive options have a negated opposite, but a lot
+do, including those that can be used to disable an implied option (e.g.
+<code>--no-D</code>, <code>--no-perms</code>) or have different defaults in various circumstances
+(e.g. <a href="#opt--no-whole-file"><code>--no-whole-file</code></a>, <code>--no-blocking-io</code>, <code>--no-dirs</code>). Every
+valid negated option accepts both the short and the long option name after
+the &quot;no-&quot; prefix (e.g. <code>--no-R</code> is the same as <code>--no-relative</code>).</p>
+<p>As an example, if you want to use <a href="#opt--archive"><code>--archive</code></a> (<code>-a</code>) but don't want
+<a href="#opt--owner"><code>--owner</code></a> (<code>-o</code>), instead of converting <code>-a</code> into <code>-rlptgD</code>, you
+can specify <code>-a --no-o</code> (aka <code>--archive --no-owner</code>).</p>
+<p>The order of the options is important: if you specify <code>--no-r -a</code>, the <code>-r</code>
+option would end up being turned on, the opposite of <code>-a --no-r</code>. Note
+also that the side-effects of the <a href="#opt--files-from"><code>--files-from</code></a> option are NOT
+positional, as it affects the default state of several options and slightly
+changes the meaning of <a href="#opt-a"><code>-a</code></a> (see the <a href="#opt--files-from"><code>--files-from</code></a> option
+for more details).</p>
+</dd>
+
+<span id="opt-r"></span><dt id="opt--recursive"><code>--recursive</code>, <code>-r</code><a href="#opt--recursive" class="tgt"></a></dt><dd>
+<p>This tells rsync to copy directories recursively. See also
+<a href="#opt--dirs"><code>--dirs</code></a> (<code>-d</code>) for an option that allows the scanning of a single
+directory.</p>
+<p>See the <a href="#opt--inc-recursive"><code>--inc-recursive</code></a> option for a discussion of the
+incremental recursion for creating the list of files to transfer.</p>
+</dd>
+
+<span id="opt--i-r"></span><dt id="opt--inc-recursive"><code>--inc-recursive</code>, <code>--i-r</code><a href="#opt--inc-recursive" class="tgt"></a></dt><dd>
+<p>This option explicitly enables on incremental recursion when scanning for
+files, which is enabled by default when using the <a href="#opt--recursive"><code>--recursive</code></a>
+option and both sides of the transfer are running rsync 3.0.0 or newer.</p>
+<p>Incremental recursion uses much less memory than non-incremental, while
+also beginning the transfer more quickly (since it doesn't need to scan the
+entire transfer hierarchy before it starts transferring files). If no
+recursion is enabled in the source files, this option has no effect.</p>
+<p>Some options require rsync to know the full file list, so these options
+disable the incremental recursion mode. These include:</p>
+<ul>
+<li><a href="#opt--delete-before"><code>--delete-before</code></a> (the old default of <a href="#opt--delete"><code>--delete</code></a>)</li>
+<li><a href="#opt--delete-after"><code>--delete-after</code></a></li>
+<li><a href="#opt--prune-empty-dirs"><code>--prune-empty-dirs</code></a></li>
+<li><a href="#opt--delay-updates"><code>--delay-updates</code></a></li>
+</ul>
+<p>In order to make <a href="#opt--delete"><code>--delete</code></a> compatible with incremental recursion,
+rsync 3.0.0 made <a href="#opt--delete-during"><code>--delete-during</code></a> the default delete mode (which
+was first added in 2.6.4).</p>
+<p>One side-effect of incremental recursion is that any missing
+sub-directories inside a recursively-scanned directory are (by default)
+created prior to recursing into the sub-dirs. This earlier creation point
+(compared to a non-incremental recursion) allows rsync to then set the
+modify time of the finished directory right away (without having to delay
+that until a bunch of recursive copying has finished). However, these
+early directories don't yet have their completed mode, mtime, or ownership
+set&nbsp;-&#8288;-&#8288; they have more restrictive rights until the subdirectory's copying
+actually begins. This early-creation idiom can be avoided by using the
+<a href="#opt--omit-dir-times"><code>--omit-dir-times</code></a> option.</p>
+<p>Incremental recursion can be disabled using the
+<a href="#opt--no-inc-recursive"><code>--no-inc-recursive</code></a> (<code>--no-i-r</code>) option.</p>
+</dd>
+
+<span id="opt--no-i-r"></span><dt id="opt--no-inc-recursive"><code>--no-inc-recursive</code>, <code>--no-i-r</code><a href="#opt--no-inc-recursive" class="tgt"></a></dt><dd>
+<p>Disables the new incremental recursion algorithm of the
+<a href="#opt--recursive"><code>--recursive</code></a> option. This makes rsync scan the full file list
+before it begins to transfer files. See <a href="#opt--inc-recursive"><code>--inc-recursive</code></a> for more
+info.</p>
+</dd>
+
+<span id="opt-R"></span><dt id="opt--relative"><code>--relative</code>, <code>-R</code><a href="#opt--relative" class="tgt"></a></dt><dd>
+<p>Use relative paths. This means that the full path names specified on the
+command line are sent to the server rather than just the last parts of the
+filenames. This is particularly useful when you want to send several
+different directories at the same time. For example, if you used this
+command:</p>
+<blockquote>
+<pre><code>rsync -av /foo/bar/baz.c remote:/tmp/
+</code></pre>
+</blockquote>
+<p>would create a file named baz.c in /tmp/ on the remote machine. If instead
+you used</p>
+<blockquote>
+<pre><code>rsync -avR /foo/bar/baz.c remote:/tmp/
+</code></pre>
+</blockquote>
+<p>then a file named /tmp/foo/bar/baz.c would be created on the remote
+machine, preserving its full path. These extra path elements are called
+&quot;implied directories&quot; (i.e. the &quot;foo&quot; and the &quot;foo/bar&quot; directories in the
+above example).</p>
+<p>Beginning with rsync 3.0.0, rsync always sends these implied directories as
+real directories in the file list, even if a path element is really a
+symlink on the sending side. This prevents some really unexpected behaviors
+when copying the full path of a file that you didn't realize had a symlink
+in its path. If you want to duplicate a server-side symlink, include both
+the symlink via its path, and referent directory via its real path. If
+you're dealing with an older rsync on the sending side, you may need to use
+the <a href="#opt--no-implied-dirs"><code>--no-implied-dirs</code></a> option.</p>
+<p>It is also possible to limit the amount of path information that is sent as
+implied directories for each path you specify. With a modern rsync on the
+sending side (beginning with 2.6.7), you can insert a dot and a slash into
+the source path, like this:</p>
+<blockquote>
+<pre><code>rsync -avR /foo/./bar/baz.c remote:/tmp/
+</code></pre>
+</blockquote>
+<p>That would create /tmp/bar/baz.c on the remote machine. (Note that the dot
+must be followed by a slash, so &quot;/foo/.&quot; would not be abbreviated.) For
+older rsync versions, you would need to use a chdir to limit the source
+path. For example, when pushing files:</p>
+<blockquote>
+<pre><code>(cd /foo; rsync -avR bar/baz.c remote:/tmp/)
+</code></pre>
+</blockquote>
+<p>(Note that the parens put the two commands into a sub-shell, so that the
+&quot;cd&quot; command doesn't remain in effect for future commands.) If you're
+pulling files from an older rsync, use this idiom (but only for a
+non-daemon transfer):</p>
+<blockquote>
+<pre><code>rsync -avR --rsync-path=&quot;cd /foo; rsync&quot; \
+ remote:bar/baz.c /tmp/
+</code></pre>
+</blockquote>
+</dd>
+
+<dt id="opt--no-implied-dirs"><code>--no-implied-dirs</code><a href="#opt--no-implied-dirs" class="tgt"></a></dt><dd>
+<p>This option affects the default behavior of the <a href="#opt--relative"><code>--relative</code></a> option. When
+it is specified, the attributes of the implied directories from the source
+names are not included in the transfer. This means that the corresponding
+path elements on the destination system are left unchanged if they exist,
+and any missing implied directories are created with default attributes.
+This even allows these implied path elements to have big differences, such
+as being a symlink to a directory on the receiving side.</p>
+<p>For instance, if a command-line arg or a files-from entry told rsync to
+transfer the file &quot;path/foo/file&quot;, the directories &quot;path&quot; and &quot;path/foo&quot;
+are implied when <a href="#opt--relative"><code>--relative</code></a> is used. If &quot;path/foo&quot; is a symlink to &quot;bar&quot;
+on the destination system, the receiving rsync would ordinarily delete
+&quot;path/foo&quot;, recreate it as a directory, and receive the file into the new
+directory. With <code>--no-implied-dirs</code>, the receiving rsync updates
+&quot;path/foo/file&quot; using the existing path elements, which means that the file
+ends up being created in &quot;path/bar&quot;. Another way to accomplish this link
+preservation is to use the <a href="#opt--keep-dirlinks"><code>--keep-dirlinks</code></a> option (which will also affect
+symlinks to directories in the rest of the transfer).</p>
+<p>When pulling files from an rsync older than 3.0.0, you may need to use this
+option if the sending side has a symlink in the path you request and you
+wish the implied directories to be transferred as normal directories.</p>
+</dd>
+
+<span id="opt-b"></span><dt id="opt--backup"><code>--backup</code>, <code>-b</code><a href="#opt--backup" class="tgt"></a></dt><dd>
+<p>With this option, preexisting destination files are renamed as each file is
+transferred or deleted. You can control where the backup file goes and
+what (if any) suffix gets appended using the <a href="#opt--backup-dir"><code>--backup-dir</code></a> and
+<a href="#opt--suffix"><code>--suffix</code></a> options.</p>
+<p>If you don't specify <a href="#opt--backup-dir"><code>--backup-dir</code></a>:</p>
+<ol>
+<li>the <a href="#opt--omit-dir-times"><code>--omit-dir-times</code></a> option will be forced on</li>
+<li>the use of <a href="#opt--delete"><code>--delete</code></a> (without <a href="#opt--delete-excluded"><code>--delete-excluded</code></a>),
+causes rsync to add a &quot;protect&quot; <a href="#FILTER_RULES">filter-rule</a> for the
+backup suffix to the end of all your existing filters that looks like
+this: <code>-f &quot;P *~&quot;</code>. This rule prevents previously backed-up files from
+being deleted.</li>
+</ol>
+<p>Note that if you are supplying your own filter rules, you may need to
+manually insert your own exclude/protect rule somewhere higher up in the
+list so that it has a high enough priority to be effective (e.g. if your
+rules specify a trailing inclusion/exclusion of <code>*</code>, the auto-added rule
+would never be reached).</p>
+</dd>
+
+<dt id="opt--backup-dir"><code>--backup-dir=DIR</code><a href="#opt--backup-dir" class="tgt"></a></dt><dd>
+<p>This implies the <a href="#opt--backup"><code>--backup</code></a> option, and tells rsync to store all
+backups in the specified directory on the receiving side. This can be used
+for incremental backups. You can additionally specify a backup suffix
+using the <a href="#opt--suffix"><code>--suffix</code></a> option (otherwise the files backed up in the
+specified directory will keep their original filenames).</p>
+<p>Note that if you specify a relative path, the backup directory will be
+relative to the destination directory, so you probably want to specify
+either an absolute path or a path that starts with &quot;../&quot;. If an rsync
+daemon is the receiver, the backup dir cannot go outside the module's path
+hierarchy, so take extra care not to delete it or copy into it.</p>
+</dd>
+
+<dt id="opt--suffix"><code>--suffix=SUFFIX</code><a href="#opt--suffix" class="tgt"></a></dt><dd>
+<p>This option allows you to override the default backup suffix used with the
+<a href="#opt--backup"><code>--backup</code></a> (<code>-b</code>) option. The default suffix is a <code>~</code> if no
+<a href="#opt--backup-dir"><code>--backup-dir</code></a> was specified, otherwise it is an empty string.</p>
+</dd>
+
+<span id="opt-u"></span><dt id="opt--update"><code>--update</code>, <code>-u</code><a href="#opt--update" class="tgt"></a></dt><dd>
+<p>This forces rsync to skip any files which exist on the destination and have
+a modified time that is newer than the source file. (If an existing
+destination file has a modification time equal to the source file's, it
+will be updated if the sizes are different.)</p>
+<p>Note that this does not affect the copying of dirs, symlinks, or other
+special files. Also, a difference of file format between the sender and
+receiver is always considered to be important enough for an update, no
+matter what date is on the objects. In other words, if the source has a
+directory where the destination has a file, the transfer would occur
+regardless of the timestamps.</p>
+<p>This option is a <a href="#TRANSFER_RULES">TRANSFER RULE</a>, so don't expect any
+exclude side effects.</p>
+<p>A caution for those that choose to combine <a href="#opt--inplace"><code>--inplace</code></a> with
+<code>--update</code>: an interrupted transfer will leave behind a partial file on the
+receiving side that has a very recent modified time, so re-running the
+transfer will probably <strong>not</strong> continue the interrupted file. As such, it
+is usually best to avoid combining this with<a href="#opt--inplace"> <code>--inplace</code></a> unless you
+have implemented manual steps to handle any interrupted in-progress files.</p>
+</dd>
+
+<dt id="opt--inplace"><code>--inplace</code><a href="#opt--inplace" class="tgt"></a></dt><dd>
+<p>This option changes how rsync transfers a file when its data needs to be
+updated: instead of the default method of creating a new copy of the file
+and moving it into place when it is complete, rsync instead writes the
+updated data directly to the destination file.</p>
+<p>This has several effects:</p>
+<ul>
+<li>Hard links are not broken. This means the new data will be visible
+through other hard links to the destination file. Moreover, attempts to
+copy differing source files onto a multiply-linked destination file will
+result in a &quot;tug of war&quot; with the destination data changing back and
+forth.</li>
+<li>In-use binaries cannot be updated (either the OS will prevent this from
+happening, or binaries that attempt to swap-in their data will misbehave
+or crash).</li>
+<li>The file's data will be in an inconsistent state during the transfer and
+will be left that way if the transfer is interrupted or if an update
+fails.</li>
+<li>A file that rsync cannot write to cannot be updated. While a super user
+can update any file, a normal user needs to be granted write permission
+for the open of the file for writing to be successful.</li>
+<li>The efficiency of rsync's delta-transfer algorithm may be reduced if some
+data in the destination file is overwritten before it can be copied to a
+position later in the file. This does not apply if you use <a href="#opt--backup"><code>--backup</code></a>,
+since rsync is smart enough to use the backup file as the basis file for
+the transfer.</li>
+</ul>
+<p>WARNING: you should not use this option to update files that are being
+accessed by others, so be careful when choosing to use this for a copy.</p>
+<p>This option is useful for transferring large files with block-based changes
+or appended data, and also on systems that are disk bound, not network
+bound. It can also help keep a copy-on-write filesystem snapshot from
+diverging the entire contents of a file that only has minor changes.</p>
+<p>The option implies <a href="#opt--partial"><code>--partial</code></a> (since an interrupted transfer does
+not delete the file), but conflicts with <a href="#opt--partial-dir"><code>--partial-dir</code></a> and
+<a href="#opt--delay-updates"><code>--delay-updates</code></a>. Prior to rsync 2.6.4 <code>--inplace</code> was also
+incompatible with <a href="#opt--compare-dest"><code>--compare-dest</code></a> and <a href="#opt--link-dest"><code>--link-dest</code></a>.</p>
+</dd>
+
+<dt id="opt--append"><code>--append</code><a href="#opt--append" class="tgt"></a></dt><dd>
+<p>This special copy mode only works to efficiently update files that are
+known to be growing larger where any existing content on the receiving side
+is also known to be the same as the content on the sender. The use of
+<code>--append</code> <strong>can be dangerous</strong> if you aren't 100% sure that all the files
+in the transfer are shared, growing files. You should thus use filter
+rules to ensure that you weed out any files that do not fit this criteria.</p>
+<p>Rsync updates these growing file in-place without verifying any of the
+existing content in the file (it only verifies the content that it is
+appending). Rsync skips any files that exist on the receiving side that
+are not shorter than the associated file on the sending side (which means
+that new files are transferred). It also skips any files whose size on the
+sending side gets shorter during the send negotiations (rsync warns about a
+&quot;diminished&quot; file when this happens).</p>
+<p>This does not interfere with the updating of a file's non-content
+attributes (e.g. permissions, ownership, etc.) when the file does not need
+to be transferred, nor does it affect the updating of any directories or
+non-regular files.</p>
+</dd>
+
+<dt id="opt--append-verify"><code>--append-verify</code><a href="#opt--append-verify" class="tgt"></a></dt><dd>
+<p>This special copy mode works like <a href="#opt--append"><code>--append</code></a> except that all the
+data in the file is included in the checksum verification (making it less
+efficient but also potentially safer). This option <strong>can be dangerous</strong> if
+you aren't 100% sure that all the files in the transfer are shared, growing
+files. See the <a href="#opt--append"><code>--append</code></a> option for more details.</p>
+<p>Note: prior to rsync 3.0.0, the <a href="#opt--append"><code>--append</code></a> option worked like
+<code>--append-verify</code>, so if you are interacting with an older rsync (or the
+transfer is using a protocol prior to 30), specifying either append option
+will initiate an <code>--append-verify</code> transfer.</p>
+</dd>
+
+<span id="opt-d"></span><dt id="opt--dirs"><code>--dirs</code>, <code>-d</code><a href="#opt--dirs" class="tgt"></a></dt><dd>
+<p>Tell the sending side to include any directories that are encountered.
+Unlike <a href="#opt--recursive"><code>--recursive</code></a>, a directory's contents are not copied unless
+the directory name specified is &quot;.&quot; or ends with a trailing slash (e.g.
+&quot;.&quot;, &quot;dir/.&quot;, &quot;dir/&quot;, etc.). Without this option or the
+<a href="#opt--recursive"><code>--recursive</code></a> option, rsync will skip all directories it encounters
+(and output a message to that effect for each one). If you specify both
+<code>--dirs</code> and <a href="#opt--recursive"><code>--recursive</code></a>, <code>--recursive</code> takes precedence.</p>
+<p>The <code>--dirs</code> option is implied by the <a href="#opt--files-from"><code>--files-from</code></a> option or the
+<a href="#opt--list-only"><code>--list-only</code></a> option (including an implied <a href="#opt--list-only"><code>--list-only</code></a>
+usage) if <a href="#opt--recursive"><code>--recursive</code></a> wasn't specified (so that directories are
+seen in the listing). Specify <code>--no-dirs</code> (or <code>--no-d</code>) if you want to
+turn this off.</p>
+<p>There is also a backward-compatibility helper option, <code>--old-dirs</code>
+(<code>--old-d</code>) that tells rsync to use a hack of <code>-r --exclude='/*/*'</code> to get
+an older rsync to list a single directory without recursing.</p>
+</dd>
+
+<dt id="opt--mkpath"><code>--mkpath</code><a href="#opt--mkpath" class="tgt"></a></dt><dd>
+<p>Create all missing path components of the destination path.</p>
+<p>By default, rsync allows only the final component of the destination path
+to not exist, which is an attempt to help you to validate your destination
+path. With this option, rsync creates all the missing destination-path
+components, just as if <code>mkdir -p $DEST_PATH</code> had been run on the receiving
+side.</p>
+<p>When specifying a destination path, including a trailing slash ensures that
+the whole path is treated as directory names to be created, even when the
+file list has a single item. See the <a href="#COPYING_TO_A_DIFFERENT_NAME">COPYING TO A DIFFERENT NAME</a>
+section for full details on how rsync decides if a final destination-path
+component should be created as a directory or not.</p>
+<p>If you would like the newly-created destination dirs to match the dirs on
+the sending side, you should be using <a href="#opt--relative"><code>--relative</code></a> (<code>-R</code>) instead
+of <code>--mkpath</code>. For instance, the following two commands result in the same
+destination tree, but only the second command ensures that the
+&quot;some/extra/path&quot; components match the dirs on the sending side:</p>
+<blockquote>
+<pre><code>rsync -ai --mkpath host:some/extra/path/*.c some/extra/path/
+rsync -aiR host:some/extra/path/*.c ./
+</code></pre>
+</blockquote>
+</dd>
+
+<span id="opt-l"></span><dt id="opt--links"><code>--links</code>, <code>-l</code><a href="#opt--links" class="tgt"></a></dt><dd>
+<p>Add symlinks to the transferred files instead of noisily ignoring them with
+a &quot;non-regular file&quot; warning for each symlink encountered. You can
+alternately silence the warning by specifying <a href="#opt--info"><code>--info=nonreg0</code></a>.</p>
+<p>The default handling of symlinks is to recreate each symlink's unchanged
+value on the receiving side.</p>
+<p>See the <a href="#SYMBOLIC_LINKS">SYMBOLIC LINKS</a> section for multi-option info.</p>
+</dd>
+
+<span id="opt-L"></span><dt id="opt--copy-links"><code>--copy-links</code>, <code>-L</code><a href="#opt--copy-links" class="tgt"></a></dt><dd>
+<p>The sender transforms each symlink encountered in the transfer into the
+referent item, following the symlink chain to the file or directory that it
+references. If a symlink chain is broken, an error is output and the file
+is dropped from the transfer.</p>
+<p>This option supersedes any other options that affect symlinks in the
+transfer, since there are no symlinks left in the transfer.</p>
+<p>This option does not change the handling of existing symlinks on the
+receiving side, unlike versions of rsync prior to 2.6.3 which had the
+side-effect of telling the receiving side to also follow symlinks. A
+modern rsync won't forward this option to a remote receiver (since only the
+sender needs to know about it), so this caveat should only affect someone
+using an rsync client older than 2.6.7 (which is when <code>-L</code> stopped being
+forwarded to the receiver).</p>
+<p>See the <a href="#opt--keep-dirlinks"><code>--keep-dirlinks</code></a> (<code>-K</code>) if you need a symlink to a
+directory to be treated as a real directory on the receiving side.</p>
+<p>See the <a href="#SYMBOLIC_LINKS">SYMBOLIC LINKS</a> section for multi-option info.</p>
+</dd>
+
+<dt id="opt--copy-unsafe-links"><code>--copy-unsafe-links</code><a href="#opt--copy-unsafe-links" class="tgt"></a></dt><dd>
+<p>This tells rsync to copy the referent of symbolic links that point outside
+the copied tree. Absolute symlinks are also treated like ordinary files,
+and so are any symlinks in the source path itself when <a href="#opt--relative"><code>--relative</code></a>
+is used.</p>
+<p>Note that the cut-off point is the top of the transfer, which is the part
+of the path that rsync isn't mentioning in the verbose output. If you copy
+&quot;/src/subdir&quot; to &quot;/dest/&quot; then the &quot;subdir&quot; directory is a name inside the
+transfer tree, not the top of the transfer (which is /src) so it is legal
+for created relative symlinks to refer to other names inside the /src and
+/dest directories. If you instead copy &quot;/src/subdir/&quot; (with a trailing
+slash) to &quot;/dest/subdir&quot; that would not allow symlinks to any files outside
+of &quot;subdir&quot;.</p>
+<p>Note that safe symlinks are only copied if <a href="#opt--links"><code>--links</code></a> was also
+specified or implied. The <code>--copy-unsafe-links</code> option has no extra effect
+when combined with <a href="#opt--copy-links"><code>--copy-links</code></a>.</p>
+<p>See the <a href="#SYMBOLIC_LINKS">SYMBOLIC LINKS</a> section for multi-option info.</p>
+</dd>
+
+<dt id="opt--safe-links"><code>--safe-links</code><a href="#opt--safe-links" class="tgt"></a></dt><dd>
+<p>This tells the receiving rsync to ignore any symbolic links in the transfer
+which point outside the copied tree. All absolute symlinks are also
+ignored.</p>
+<p>Since this ignoring is happening on the receiving side, it will still be
+effective even when the sending side has munged symlinks (when it is using
+<a href="#opt--munge-links"><code>--munge-links</code></a>). It also affects deletions, since the file being
+present in the transfer prevents any matching file on the receiver from
+being deleted when the symlink is deemed to be unsafe and is skipped.</p>
+<p>This option must be combined with <a href="#opt--links"><code>--links</code></a> (or
+<a href="#opt--archive"><code>--archive</code></a>) to have any symlinks in the transfer to conditionally
+ignore. Its effect is superseded by <a href="#opt--copy-unsafe-links"><code>--copy-unsafe-links</code></a>.</p>
+<p>Using this option in conjunction with <a href="#opt--relative"><code>--relative</code></a> may give
+unexpected results.</p>
+<p>See the <a href="#SYMBOLIC_LINKS">SYMBOLIC LINKS</a> section for multi-option info.</p>
+</dd>
+
+<dt id="opt--munge-links"><code>--munge-links</code><a href="#opt--munge-links" class="tgt"></a></dt><dd>
+<p>This option affects just one side of the transfer and tells rsync to munge
+symlink values when it is receiving files or unmunge symlink values when it
+is sending files. The munged values make the symlinks unusable on disk but
+allows the original contents of the symlinks to be recovered.</p>
+<p>The server-side rsync often enables this option without the client's
+knowledge, such as in an rsync daemon's configuration file or by an option
+given to the rrsync (restricted rsync) script. When specified on the
+client side, specify the option normally if it is the client side that
+has/needs the munged symlinks, or use <code>-M--munge-links</code> to give the option
+to the server when it has/needs the munged symlinks. Note that on a local
+transfer, the client is the sender, so specifying the option directly
+unmunges symlinks while specifying it as a remote option munges symlinks.</p>
+<p>This option has no effect when sent to a daemon via <a href="#opt--remote-option"><code>--remote-option</code></a>
+because the daemon configures whether it wants munged symlinks via its
+&quot;<code>munge symlinks</code>&quot; parameter.</p>
+<p>The symlink value is munged/unmunged once it is in the transfer, so any
+option that transforms symlinks into non-symlinks occurs prior to the
+munging/unmunging <strong>except</strong> for <a href="#opt--safe-links"><code>--safe-links</code></a>, which is a choice
+that the receiver makes, so it bases its decision on the munged/unmunged
+value. This does mean that if a receiver has munging enabled, that using
+<a href="#opt--safe-links"><code>--safe-links</code></a> will cause all symlinks to be ignored (since they
+are all absolute).</p>
+<p>The method that rsync uses to munge the symlinks is to prefix each one's
+value with the string &quot;/rsyncd-munged/&quot;. This prevents the links from
+being used as long as the directory does not exist. When this option is
+enabled, rsync will refuse to run if that path is a directory or a symlink
+to a directory (though it only checks at startup). See also the
+&quot;munge-symlinks&quot; python script in the support directory of the source code
+for a way to munge/unmunge one or more symlinks in-place.</p>
+</dd>
+
+<span id="opt-k"></span><dt id="opt--copy-dirlinks"><code>--copy-dirlinks</code>, <code>-k</code><a href="#opt--copy-dirlinks" class="tgt"></a></dt><dd>
+<p>This option causes the sending side to treat a symlink to a directory as
+though it were a real directory. This is useful if you don't want symlinks
+to non-directories to be affected, as they would be using
+<a href="#opt--copy-links"><code>--copy-links</code></a>.</p>
+<p>Without this option, if the sending side has replaced a directory with a
+symlink to a directory, the receiving side will delete anything that is in
+the way of the new symlink, including a directory hierarchy (as long as
+<a href="#opt--force"><code>--force</code></a> or <a href="#opt--delete"><code>--delete</code></a> is in effect).</p>
+<p>See also <a href="#opt--keep-dirlinks"><code>--keep-dirlinks</code></a> for an analogous option for the
+receiving side.</p>
+<p><code>--copy-dirlinks</code> applies to all symlinks to directories in the source. If
+you want to follow only a few specified symlinks, a trick you can use is to
+pass them as additional source args with a trailing slash, using
+<a href="#opt--relative"><code>--relative</code></a> to make the paths match up right. For example:</p>
+<blockquote>
+<pre><code>rsync -r --relative src/./ src/./follow-me/ dest/
+</code></pre>
+</blockquote>
+<p>This works because rsync calls <strong>lstat</strong>(2) on the source arg as given, and
+the trailing slash makes <strong>lstat</strong>(2) follow the symlink, giving rise to a
+directory in the file-list which overrides the symlink found during the
+scan of &quot;src/./&quot;.</p>
+<p>See the <a href="#SYMBOLIC_LINKS">SYMBOLIC LINKS</a> section for multi-option info.</p>
+</dd>
+
+<span id="opt-K"></span><dt id="opt--keep-dirlinks"><code>--keep-dirlinks</code>, <code>-K</code><a href="#opt--keep-dirlinks" class="tgt"></a></dt><dd>
+<p>This option causes the receiving side to treat a symlink to a directory as
+though it were a real directory, but only if it matches a real directory
+from the sender. Without this option, the receiver's symlink would be
+deleted and replaced with a real directory.</p>
+<p>For example, suppose you transfer a directory &quot;foo&quot; that contains a file
+&quot;file&quot;, but &quot;foo&quot; is a symlink to directory &quot;bar&quot; on the receiver. Without
+<code>--keep-dirlinks</code>, the receiver deletes symlink &quot;foo&quot;, recreates it as a
+directory, and receives the file into the new directory. With
+<code>--keep-dirlinks</code>, the receiver keeps the symlink and &quot;file&quot; ends up in
+&quot;bar&quot;.</p>
+<p>One note of caution: if you use <code>--keep-dirlinks</code>, you must trust all the
+symlinks in the copy or enable the <a href="#opt--munge-links"><code>--munge-links</code></a> option on the
+receiving side! If it is possible for an untrusted user to create their
+own symlink to any real directory, the user could then (on a subsequent
+copy) replace the symlink with a real directory and affect the content of
+whatever directory the symlink references. For backup copies, you are
+better off using something like a bind mount instead of a symlink to modify
+your receiving hierarchy.</p>
+<p>See also <a href="#opt--copy-dirlinks"><code>--copy-dirlinks</code></a> for an analogous option for the sending
+side.</p>
+<p>See the <a href="#SYMBOLIC_LINKS">SYMBOLIC LINKS</a> section for multi-option info.</p>
+</dd>
+
+<span id="opt-H"></span><dt id="opt--hard-links"><code>--hard-links</code>, <code>-H</code><a href="#opt--hard-links" class="tgt"></a></dt><dd>
+<p>This tells rsync to look for hard-linked files in the source and link
+together the corresponding files on the destination. Without this option,
+hard-linked files in the source are treated as though they were separate
+files.</p>
+<p>This option does NOT necessarily ensure that the pattern of hard links on
+the destination exactly matches that on the source. Cases in which the
+destination may end up with extra hard links include the following:</p>
+<ul>
+<li>If the destination contains extraneous hard-links (more linking than what
+is present in the source file list), the copying algorithm will not break
+them explicitly. However, if one or more of the paths have content
+differences, the normal file-update process will break those extra links
+(unless you are using the <a href="#opt--inplace"><code>--inplace</code></a> option).</li>
+<li>If you specify a <a href="#opt--link-dest"><code>--link-dest</code></a> directory that contains hard
+links, the linking of the destination files against the
+<a href="#opt--link-dest"><code>--link-dest</code></a> files can cause some paths in the destination to
+become linked together due to the <a href="#opt--link-dest"><code>--link-dest</code></a> associations.</li>
+</ul>
+<p>Note that rsync can only detect hard links between files that are inside
+the transfer set. If rsync updates a file that has extra hard-link
+connections to files outside the transfer, that linkage will be broken. If
+you are tempted to use the <a href="#opt--inplace"><code>--inplace</code></a> option to avoid this breakage, be
+very careful that you know how your files are being updated so that you are
+certain that no unintended changes happen due to lingering hard links (and
+see the <a href="#opt--inplace"><code>--inplace</code></a> option for more caveats).</p>
+<p>If incremental recursion is active (see <a href="#opt--inc-recursive"><code>--inc-recursive</code></a>), rsync
+may transfer a missing hard-linked file before it finds that another link
+for that contents exists elsewhere in the hierarchy. This does not affect
+the accuracy of the transfer (i.e. which files are hard-linked together),
+just its efficiency (i.e. copying the data for a new, early copy of a
+hard-linked file that could have been found later in the transfer in
+another member of the hard-linked set of files). One way to avoid this
+inefficiency is to disable incremental recursion using the
+<a href="#opt--no-inc-recursive"><code>--no-inc-recursive</code></a> option.</p>
+</dd>
+
+<span id="opt-p"></span><dt id="opt--perms"><code>--perms</code>, <code>-p</code><a href="#opt--perms" class="tgt"></a></dt><dd>
+<p>This option causes the receiving rsync to set the destination permissions
+to be the same as the source permissions. (See also the <a href="#opt--chmod"><code>--chmod</code></a>
+option for a way to modify what rsync considers to be the source
+permissions.)</p>
+<p>When this option is <u>off</u>, permissions are set as follows:</p>
+<ul>
+<li>Existing files (including updated files) retain their existing
+permissions, though the <a href="#opt--executability"><code>--executability</code></a> option might change
+just the execute permission for the file.</li>
+<li>New files get their &quot;normal&quot; permission bits set to the source file's
+permissions masked with the receiving directory's default permissions
+(either the receiving process's umask, or the permissions specified via
+the destination directory's default ACL), and their special permission
+bits disabled except in the case where a new directory inherits a setgid
+bit from its parent directory.</li>
+</ul>
+<p>Thus, when <code>--perms</code> and <a href="#opt--executability"><code>--executability</code></a> are both disabled, rsync's
+behavior is the same as that of other file-copy utilities, such as <strong>cp</strong>(1)
+and <strong>tar</strong>(1).</p>
+<p>In summary: to give destination files (both old and new) the source
+permissions, use <code>--perms</code>. To give new files the destination-default
+permissions (while leaving existing files unchanged), make sure that the
+<code>--perms</code> option is off and use <a href="#opt--chmod"><code>--chmod=ugo=rwX</code></a> (which ensures
+that all non-masked bits get enabled). If you'd care to make this latter
+behavior easier to type, you could define a popt alias for it, such as
+putting this line in the file <code>~/.popt</code> (the following defines the <code>-Z</code>
+option, and includes <code>--no-g</code> to use the default group of the destination
+dir):</p>
+<blockquote>
+<pre><code> rsync alias -Z --no-p --no-g --chmod=ugo=rwX
+</code></pre>
+</blockquote>
+<p>You could then use this new option in a command such as this one:</p>
+<blockquote>
+<pre><code> rsync -avZ src/ dest/
+</code></pre>
+</blockquote>
+<p>(Caveat: make sure that <code>-a</code> does not follow <code>-Z</code>, or it will re-enable the
+two <code>--no-*</code> options mentioned above.)</p>
+<p>The preservation of the destination's setgid bit on newly-created
+directories when <code>--perms</code> is off was added in rsync 2.6.7. Older rsync
+versions erroneously preserved the three special permission bits for
+newly-created files when <code>--perms</code> was off, while overriding the
+destination's setgid bit setting on a newly-created directory. Default ACL
+observance was added to the ACL patch for rsync 2.6.7, so older (or
+non-ACL-enabled) rsyncs use the umask even if default ACLs are present.
+(Keep in mind that it is the version of the receiving rsync that affects
+these behaviors.)</p>
+</dd>
+
+<span id="opt-E"></span><dt id="opt--executability"><code>--executability</code>, <code>-E</code><a href="#opt--executability" class="tgt"></a></dt><dd>
+<p>This option causes rsync to preserve the executability (or
+non-executability) of regular files when <a href="#opt--perms"><code>--perms</code></a> is not enabled.
+A regular file is considered to be executable if at least one 'x' is turned
+on in its permissions. When an existing destination file's executability
+differs from that of the corresponding source file, rsync modifies the
+destination file's permissions as follows:</p>
+<ul>
+<li>To make a file non-executable, rsync turns off all its 'x' permissions.</li>
+<li>To make a file executable, rsync turns on each 'x' permission that has a
+corresponding 'r' permission enabled.</li>
+</ul>
+<p>If <a href="#opt--perms"><code>--perms</code></a> is enabled, this option is ignored.</p>
+</dd>
+
+<span id="opt-A"></span><dt id="opt--acls"><code>--acls</code>, <code>-A</code><a href="#opt--acls" class="tgt"></a></dt><dd>
+<p>This option causes rsync to update the destination ACLs to be the same as
+the source ACLs. The option also implies <a href="#opt--perms"><code>--perms</code></a>.</p>
+<p>The source and destination systems must have compatible ACL entries for
+this option to work properly. See the <a href="#opt--fake-super"><code>--fake-super</code></a> option for a
+way to backup and restore ACLs that are not compatible.</p>
+</dd>
+
+<span id="opt-X"></span><dt id="opt--xattrs"><code>--xattrs</code>, <code>-X</code><a href="#opt--xattrs" class="tgt"></a></dt><dd>
+<p>This option causes rsync to update the destination extended attributes to
+be the same as the source ones.</p>
+<p>For systems that support extended-attribute namespaces, a copy being done
+by a super-user copies all namespaces except system.*. A normal user only
+copies the user.* namespace. To be able to backup and restore non-user
+namespaces as a normal user, see the <a href="#opt--fake-super"><code>--fake-super</code></a> option.</p>
+<p>The above name filtering can be overridden by using one or more filter
+options with the <strong>x</strong> modifier. When you specify an xattr-affecting
+filter rule, rsync requires that you do your own system/user filtering, as
+well as any additional filtering for what xattr names are copied and what
+names are allowed to be deleted. For example, to skip the system
+namespace, you could specify:</p>
+<blockquote>
+<pre><code>--filter='-x system.*'
+</code></pre>
+</blockquote>
+<p>To skip all namespaces except the user namespace, you could specify a
+negated-user match:</p>
+<blockquote>
+<pre><code>--filter='-x! user.*'
+</code></pre>
+</blockquote>
+<p>To prevent any attributes from being deleted, you could specify a
+receiver-only rule that excludes all names:</p>
+<blockquote>
+<pre><code>--filter='-xr *'
+</code></pre>
+</blockquote>
+<p>Note that the <code>-X</code> option does not copy rsync's special xattr values (e.g.
+those used by <a href="#opt--fake-super"><code>--fake-super</code></a>) unless you repeat the option (e.g. <code>-XX</code>).
+This &quot;copy all xattrs&quot; mode cannot be used with <a href="#opt--fake-super"><code>--fake-super</code></a>.</p>
+</dd>
+
+<dt id="opt--chmod"><code>--chmod=CHMOD</code><a href="#opt--chmod" class="tgt"></a></dt><dd>
+<p>This option tells rsync to apply one or more comma-separated &quot;chmod&quot; modes
+to the permission of the files in the transfer. The resulting value is
+treated as though it were the permissions that the sending side supplied
+for the file, which means that this option can seem to have no effect on
+existing files if <a href="#opt--perms"><code>--perms</code></a> is not enabled.</p>
+<p>In addition to the normal parsing rules specified in the <strong>chmod</strong>(1)
+manpage, you can specify an item that should only apply to a directory by
+prefixing it with a 'D', or specify an item that should only apply to a
+file by prefixing it with a 'F'. For example, the following will ensure
+that all directories get marked set-gid, that no files are other-writable,
+that both are user-writable and group-writable, and that both have
+consistent executability across all bits:</p>
+<blockquote>
+<pre><code>--chmod=Dg+s,ug+w,Fo-w,+X
+</code></pre>
+</blockquote>
+<p>Using octal mode numbers is also allowed:</p>
+<blockquote>
+<pre><code>--chmod=D2775,F664
+</code></pre>
+</blockquote>
+<p>It is also legal to specify multiple <code>--chmod</code> options, as each additional
+option is just appended to the list of changes to make.</p>
+<p>See the <a href="#opt--perms"><code>--perms</code></a> and <a href="#opt--executability"><code>--executability</code></a> options for how the
+resulting permission value can be applied to the files in the transfer.</p>
+</dd>
+
+<span id="opt-o"></span><dt id="opt--owner"><code>--owner</code>, <code>-o</code><a href="#opt--owner" class="tgt"></a></dt><dd>
+<p>This option causes rsync to set the owner of the destination file to be the
+same as the source file, but only if the receiving rsync is being run as
+the super-user (see also the <a href="#opt--super"><code>--super</code></a> and <a href="#opt--fake-super"><code>--fake-super</code></a>
+options). Without this option, the owner of new and/or transferred files
+are set to the invoking user on the receiving side.</p>
+<p>The preservation of ownership will associate matching names by default, but
+may fall back to using the ID number in some circumstances (see also the
+<a href="#opt--numeric-ids"><code>--numeric-ids</code></a> option for a full discussion).</p>
+</dd>
+
+<span id="opt-g"></span><dt id="opt--group"><code>--group</code>, <code>-g</code><a href="#opt--group" class="tgt"></a></dt><dd>
+<p>This option causes rsync to set the group of the destination file to be the
+same as the source file. If the receiving program is not running as the
+super-user (or if <code>--no-super</code> was specified), only groups that the
+invoking user on the receiving side is a member of will be preserved.
+Without this option, the group is set to the default group of the invoking
+user on the receiving side.</p>
+<p>The preservation of group information will associate matching names by
+default, but may fall back to using the ID number in some circumstances
+(see also the <a href="#opt--numeric-ids"><code>--numeric-ids</code></a> option for a full discussion).</p>
+</dd>
+
+<dt id="opt--devices"><code>--devices</code><a href="#opt--devices" class="tgt"></a></dt><dd>
+<p>This option causes rsync to transfer character and block device files to
+the remote system to recreate these devices. If the receiving rsync is not
+being run as the super-user, rsync silently skips creating the device files
+(see also the <a href="#opt--super"><code>--super</code></a> and <a href="#opt--fake-super"><code>--fake-super</code></a> options).</p>
+<p>By default, rsync generates a &quot;non-regular file&quot; warning for each device
+file encountered when this option is not set. You can silence the warning
+by specifying <a href="#opt--info"><code>--info=nonreg0</code></a>.</p>
+</dd>
+
+<dt id="opt--specials"><code>--specials</code><a href="#opt--specials" class="tgt"></a></dt><dd>
+<p>This option causes rsync to transfer special files, such as named sockets
+and fifos. If the receiving rsync is not being run as the super-user,
+rsync silently skips creating the special files (see also the
+<a href="#opt--super"><code>--super</code></a> and <a href="#opt--fake-super"><code>--fake-super</code></a> options).</p>
+<p>By default, rsync generates a &quot;non-regular file&quot; warning for each special
+file encountered when this option is not set. You can silence the warning
+by specifying <a href="#opt--info"><code>--info=nonreg0</code></a>.</p>
+</dd>
+
+<dt id="opt-D"><code>-D</code><a href="#opt-D" class="tgt"></a></dt><dd>
+<p>The <code>-D</code> option is equivalent to &quot;<a href="#opt--devices"><code>--devices</code></a>
+<a href="#opt--specials"><code>--specials</code></a>&quot;.</p>
+</dd>
+
+<dt id="opt--copy-devices"><code>--copy-devices</code><a href="#opt--copy-devices" class="tgt"></a></dt><dd>
+<p>This tells rsync to treat a device on the sending side as a regular file,
+allowing it to be copied to a normal destination file (or another device
+if <code>--write-devices</code> was also specified).</p>
+<p>This option is refused by default by an rsync daemon.</p>
+</dd>
+
+<dt id="opt--write-devices"><code>--write-devices</code><a href="#opt--write-devices" class="tgt"></a></dt><dd>
+<p>This tells rsync to treat a device on the receiving side as a regular file,
+allowing the writing of file data into a device.</p>
+<p>This option implies the <a href="#opt--inplace"><code>--inplace</code></a> option.</p>
+<p>Be careful using this, as you should know what devices are present on the
+receiving side of the transfer, especially when running rsync as root.</p>
+<p>This option is refused by default by an rsync daemon.</p>
+</dd>
+
+<span id="opt-t"></span><dt id="opt--times"><code>--times</code>, <code>-t</code><a href="#opt--times" class="tgt"></a></dt><dd>
+<p>This tells rsync to transfer modification times along with the files and
+update them on the remote system. Note that if this option is not used,
+the optimization that excludes files that have not been modified cannot be
+effective; in other words, a missing <code>-t</code> (or <a href="#opt-a"><code>-a</code></a>) will cause the
+next transfer to behave as if it used <a href="#opt--ignore-times"><code>--ignore-times</code></a> (<code>-I</code>),
+causing all files to be updated (though rsync's delta-transfer algorithm
+will make the update fairly efficient if the files haven't actually
+changed, you're much better off using <code>-t</code>).</p>
+<p>A modern rsync that is using transfer protocol 30 or 31 conveys a modify
+time using up to 8-bytes. If rsync is forced to speak an older protocol
+(perhaps due to the remote rsync being older than 3.0.0) a modify time is
+conveyed using 4-bytes. Prior to 3.2.7, these shorter values could convey
+a date range of 13-Dec-1901 to 19-Jan-2038. Beginning with 3.2.7, these
+4-byte values now convey a date range of 1-Jan-1970 to 7-Feb-2106. If you
+have files dated older than 1970, make sure your rsync executables are
+upgraded so that the full range of dates can be conveyed.</p>
+</dd>
+
+<span id="opt-U"></span><dt id="opt--atimes"><code>--atimes</code>, <code>-U</code><a href="#opt--atimes" class="tgt"></a></dt><dd>
+<p>This tells rsync to set the access (use) times of the destination files to
+the same value as the source files.</p>
+<p>If repeated, it also sets the <a href="#opt--open-noatime"><code>--open-noatime</code></a> option, which can help you
+to make the sending and receiving systems have the same access times on the
+transferred files without needing to run rsync an extra time after a file
+is transferred.</p>
+<p>Note that some older rsync versions (prior to 3.2.0) may have been built
+with a pre-release <code>--atimes</code> patch that does not imply
+<a href="#opt--open-noatime"><code>--open-noatime</code></a> when this option is repeated.</p>
+</dd>
+
+<dt id="opt--open-noatime"><code>--open-noatime</code><a href="#opt--open-noatime" class="tgt"></a></dt><dd>
+<p>This tells rsync to open files with the O_NOATIME flag (on systems that
+support it) to avoid changing the access time of the files that are being
+transferred. If your OS does not support the O_NOATIME flag then rsync
+will silently ignore this option. Note also that some filesystems are
+mounted to avoid updating the atime on read access even without the
+O_NOATIME flag being set.</p>
+</dd>
+
+<span id="opt-N_"></span><dt id="opt--crtimes"><code>--crtimes</code>, <code>-N,</code><a href="#opt--crtimes" class="tgt"></a></dt><dd>
+<p>This tells rsync to set the create times (newness) of the destination
+files to the same value as the source files.</p>
+</dd>
+
+<span id="opt-O"></span><dt id="opt--omit-dir-times"><code>--omit-dir-times</code>, <code>-O</code><a href="#opt--omit-dir-times" class="tgt"></a></dt><dd>
+<p>This tells rsync to omit directories when it is preserving modification,
+access, and create times. If NFS is sharing the directories on the receiving
+side, it is a good idea to use <code>-O</code>. This option is inferred if you use
+<a href="#opt--backup"><code>--backup</code></a> without <a href="#opt--backup-dir"><code>--backup-dir</code></a>.</p>
+<p>This option also has the side-effect of avoiding early creation of missing
+sub-directories when incremental recursion is enabled, as discussed in the
+<a href="#opt--inc-recursive"><code>--inc-recursive</code></a> section.</p>
+</dd>
+
+<span id="opt-J"></span><dt id="opt--omit-link-times"><code>--omit-link-times</code>, <code>-J</code><a href="#opt--omit-link-times" class="tgt"></a></dt><dd>
+<p>This tells rsync to omit symlinks when it is preserving modification,
+access, and create times.</p>
+</dd>
+
+<dt id="opt--super"><code>--super</code><a href="#opt--super" class="tgt"></a></dt><dd>
+<p>This tells the receiving side to attempt super-user activities even if the
+receiving rsync wasn't run by the super-user. These activities include:
+preserving users via the <a href="#opt--owner"><code>--owner</code></a> option, preserving all groups
+(not just the current user's groups) via the <a href="#opt--group"><code>--group</code></a> option, and
+copying devices via the <a href="#opt--devices"><code>--devices</code></a> option. This is useful for
+systems that allow such activities without being the super-user, and also
+for ensuring that you will get errors if the receiving side isn't being run
+as the super-user. To turn off super-user activities, the super-user can
+use <code>--no-super</code>.</p>
+</dd>
+
+<dt id="opt--fake-super"><code>--fake-super</code><a href="#opt--fake-super" class="tgt"></a></dt><dd>
+<p>When this option is enabled, rsync simulates super-user activities by
+saving/restoring the privileged attributes via special extended attributes
+that are attached to each file (as needed). This includes the file's owner
+and group (if it is not the default), the file's device info (device &amp;
+special files are created as empty text files), and any permission bits
+that we won't allow to be set on the real file (e.g. the real file gets
+u-s,g-s,o-t for safety) or that would limit the owner's access (since the
+real super-user can always access/change a file, the files we create can
+always be accessed/changed by the creating user). This option also handles
+ACLs (if <a href="#opt--acls"><code>--acls</code></a> was specified) and non-user extended attributes
+(if <a href="#opt--xattrs"><code>--xattrs</code></a> was specified).</p>
+<p>This is a good way to backup data without using a super-user, and to store
+ACLs from incompatible systems.</p>
+<p>The <code>--fake-super</code> option only affects the side where the option is used.
+To affect the remote side of a remote-shell connection, use the
+<a href="#opt--remote-option"><code>--remote-option</code></a> (<code>-M</code>) option:</p>
+<blockquote>
+<pre><code>rsync -av -M--fake-super /src/ host:/dest/
+</code></pre>
+</blockquote>
+<p>For a local copy, this option affects both the source and the destination.
+If you wish a local copy to enable this option just for the destination
+files, specify <code>-M--fake-super</code>. If you wish a local copy to enable this
+option just for the source files, combine <code>--fake-super</code> with <code>-M--super</code>.</p>
+<p>This option is overridden by both <a href="#opt--super"><code>--super</code></a> and <code>--no-super</code>.</p>
+<p>See also the <a href="rsyncd.conf.5#fake_super"><code>fake super</code></a> setting in the
+daemon's rsyncd.conf file.</p>
+</dd>
+
+<span id="opt-S"></span><dt id="opt--sparse"><code>--sparse</code>, <code>-S</code><a href="#opt--sparse" class="tgt"></a></dt><dd>
+<p>Try to handle sparse files efficiently so they take up less space on the
+destination. If combined with <a href="#opt--inplace"><code>--inplace</code></a> the file created might
+not end up with sparse blocks with some combinations of kernel version
+and/or filesystem type. If <a href="#opt--whole-file"><code>--whole-file</code></a> is in effect (e.g. for a
+local copy) then it will always work because rsync truncates the file prior
+to writing out the updated version.</p>
+<p>Note that versions of rsync older than 3.1.3 will reject the combination of
+<code>--sparse</code> and <a href="#opt--inplace"><code>--inplace</code></a>.</p>
+</dd>
+
+<dt id="opt--preallocate"><code>--preallocate</code><a href="#opt--preallocate" class="tgt"></a></dt><dd>
+<p>This tells the receiver to allocate each destination file to its eventual
+size before writing data to the file. Rsync will only use the real
+filesystem-level preallocation support provided by Linux's <strong>fallocate</strong>(2)
+system call or Cygwin's <strong>posix_fallocate</strong>(3), not the slow glibc
+implementation that writes a null byte into each block.</p>
+<p>Without this option, larger files may not be entirely contiguous on the
+filesystem, but with this option rsync will probably copy more slowly. If
+the destination is not an extent-supporting filesystem (such as ext4, xfs,
+NTFS, etc.), this option may have no positive effect at all.</p>
+<p>If combined with <a href="#opt--sparse"><code>--sparse</code></a>, the file will only have sparse blocks
+(as opposed to allocated sequences of null bytes) if the kernel version and
+filesystem type support creating holes in the allocated data.</p>
+</dd>
+
+<span id="opt-n"></span><dt id="opt--dry-run"><code>--dry-run</code>, <code>-n</code><a href="#opt--dry-run" class="tgt"></a></dt><dd>
+<p>This makes rsync perform a trial run that doesn't make any changes (and
+produces mostly the same output as a real run). It is most commonly used
+in combination with the <a href="#opt--verbose"><code>--verbose</code></a> (<code>-v</code>) and/or
+<a href="#opt--itemize-changes"><code>--itemize-changes</code></a> (<code>-i</code>) options to see what an rsync command is
+going to do before one actually runs it.</p>
+<p>The output of <a href="#opt--itemize-changes"><code>--itemize-changes</code></a> is supposed to be exactly the
+same on a dry run and a subsequent real run (barring intentional trickery
+and system call failures); if it isn't, that's a bug. Other output should
+be mostly unchanged, but may differ in some areas. Notably, a dry run does
+not send the actual data for file transfers, so <a href="#opt--progress"><code>--progress</code></a> has no
+effect, the &quot;bytes sent&quot;, &quot;bytes received&quot;, &quot;literal data&quot;, and &quot;matched
+data&quot; statistics are too small, and the &quot;speedup&quot; value is equivalent to a
+run where no file transfers were needed.</p>
+</dd>
+
+<span id="opt-W"></span><dt id="opt--whole-file"><code>--whole-file</code>, <code>-W</code><a href="#opt--whole-file" class="tgt"></a></dt><dd>
+<p>This option disables rsync's delta-transfer algorithm, which causes all
+transferred files to be sent whole. The transfer may be faster if this
+option is used when the bandwidth between the source and destination
+machines is higher than the bandwidth to disk (especially when the &quot;disk&quot;
+is actually a networked filesystem). This is the default when both the
+source and destination are specified as local paths, but only if no
+batch-writing option is in effect.</p>
+</dd>
+
+<span id="opt--no-W"></span><dt id="opt--no-whole-file"><code>--no-whole-file</code>, <code>--no-W</code><a href="#opt--no-whole-file" class="tgt"></a></dt><dd>
+<p>Disable whole-file updating when it is enabled by default for a local
+transfer. This usually slows rsync down, but it can be useful if you are
+trying to minimize the writes to the destination file (if combined with
+<a href="#opt--inplace"><code>--inplace</code></a>) or for testing the checksum-based update algorithm.</p>
+<p>See also the <a href="#opt--whole-file"><code>--whole-file</code></a> option.</p>
+</dd>
+
+<span id="opt--cc"></span><dt id="opt--checksum-choice"><code>--checksum-choice=STR</code>, <code>--cc=STR</code><a href="#opt--checksum-choice" class="tgt"></a></dt><dd>
+<p>This option overrides the checksum algorithms. If one algorithm name is
+specified, it is used for both the transfer checksums and (assuming
+<a href="#opt--checksum"><code>--checksum</code></a> is specified) the pre-transfer checksums. If two
+comma-separated names are supplied, the first name affects the transfer
+checksums, and the second name affects the pre-transfer checksums (<code>-c</code>).</p>
+<p>The checksum options that you may be able to use are:</p>
+<ul>
+<li><code>auto</code> (the default automatic choice)</li>
+<li><code>xxh128</code></li>
+<li><code>xxh3</code></li>
+<li><code>xxh64</code> (aka <code>xxhash</code>)</li>
+<li><code>md5</code></li>
+<li><code>md4</code></li>
+<li><code>sha1</code></li>
+<li><code>none</code></li>
+</ul>
+<p>Run <code>rsync --version</code> to see the default checksum list compiled into your
+version (which may differ from the list above).</p>
+<p>If &quot;none&quot; is specified for the first (or only) name, the <a href="#opt--whole-file"><code>--whole-file</code></a>
+option is forced on and no checksum verification is performed on the
+transferred data. If &quot;none&quot; is specified for the second (or only) name,
+the <a href="#opt--checksum"><code>--checksum</code></a> option cannot be used.</p>
+<p>The &quot;auto&quot; option is the default, where rsync bases its algorithm choice on
+a negotiation between the client and the server as follows:</p>
+<p>When both sides of the transfer are at least 3.2.0, rsync chooses the first
+algorithm in the client's list of choices that is also in the server's list
+of choices. If no common checksum choice is found, rsync exits with
+an error. If the remote rsync is too old to support checksum negotiation,
+a value is chosen based on the protocol version (which chooses between MD5
+and various flavors of MD4 based on protocol age).</p>
+<p>The default order can be customized by setting the environment variable
+<a href="#RSYNC_CHECKSUM_LIST"><code>RSYNC_CHECKSUM_LIST</code></a> to a space-separated list of acceptable checksum
+names. If the string contains a &quot;<code>&amp;</code>&quot; character, it is separated into the
+&quot;client string &amp; server string&quot;, otherwise the same string applies to both.
+If the string (or string portion) contains no non-whitespace characters,
+the default checksum list is used. This method does not allow you to
+specify the transfer checksum separately from the pre-transfer checksum,
+and it discards &quot;auto&quot; and all unknown checksum names. A list with only
+invalid names results in a failed negotiation.</p>
+<p>The use of the <code>--checksum-choice</code> option overrides this environment list.</p>
+</dd>
+
+<span id="opt-x"></span><dt id="opt--one-file-system"><code>--one-file-system</code>, <code>-x</code><a href="#opt--one-file-system" class="tgt"></a></dt><dd>
+<p>This tells rsync to avoid crossing a filesystem boundary when recursing.
+This does not limit the user's ability to specify items to copy from
+multiple filesystems, just rsync's recursion through the hierarchy of each
+directory that the user specified, and also the analogous recursion on the
+receiving side during deletion. Also keep in mind that rsync treats a
+&quot;bind&quot; mount to the same device as being on the same filesystem.</p>
+<p>If this option is repeated, rsync omits all mount-point directories from
+the copy. Otherwise, it includes an empty directory at each mount-point it
+encounters (using the attributes of the mounted directory because those of
+the underlying mount-point directory are inaccessible).</p>
+<p>If rsync has been told to collapse symlinks (via <a href="#opt--copy-links"><code>--copy-links</code></a> or
+<a href="#opt--copy-unsafe-links"><code>--copy-unsafe-links</code></a>), a symlink to a directory on another device
+is treated like a mount-point. Symlinks to non-directories are unaffected
+by this option.</p>
+</dd>
+
+<span id="opt--existing"></span><dt id="opt--ignore-non-existing"><code>--ignore-non-existing</code>, <code>--existing</code><a href="#opt--ignore-non-existing" class="tgt"></a></dt><dd>
+<p>This tells rsync to skip creating files (including directories) that do not
+exist yet on the destination. If this option is combined with the
+<a href="#opt--ignore-existing"><code>--ignore-existing</code></a> option, no files will be updated (which can be
+useful if all you want to do is delete extraneous files).</p>
+<p>This option is a <a href="#TRANSFER_RULES">TRANSFER RULE</a>, so don't expect any
+exclude side effects.</p>
+</dd>
+
+<dt id="opt--ignore-existing"><code>--ignore-existing</code><a href="#opt--ignore-existing" class="tgt"></a></dt><dd>
+<p>This tells rsync to skip updating files that already exist on the
+destination (this does <u>not</u> ignore existing directories, or nothing would
+get done). See also <a href="#opt--ignore-non-existing"><code>--ignore-non-existing</code></a>.</p>
+<p>This option is a <a href="#TRANSFER_RULES">TRANSFER RULE</a>, so don't expect any
+exclude side effects.</p>
+<p>This option can be useful for those doing backups using the
+<a href="#opt--link-dest"><code>--link-dest</code></a> option when they need to continue a backup run that
+got interrupted. Since a <a href="#opt--link-dest"><code>--link-dest</code></a> run is copied into a new
+directory hierarchy (when it is used properly), using [<code>--ignore-existing</code>
+will ensure that the already-handled files don't get tweaked (which avoids
+a change in permissions on the hard-linked files). This does mean that
+this option is only looking at the existing files in the destination
+hierarchy itself.</p>
+<p>When <a href="#opt--info"><code>--info=skip2</code></a> is used rsync will output &quot;FILENAME exists
+(INFO)&quot; messages where the INFO indicates one of &quot;type change&quot;, &quot;sum
+change&quot; (requires <a href="#opt-c"><code>-c</code></a>), &quot;file change&quot; (based on the quick check),
+&quot;attr change&quot;, or &quot;uptodate&quot;. Using <a href="#opt--info"><code>--info=skip1</code></a> (which is also
+implied by 2 <a href="#opt-v"><code>-v</code></a> options) outputs the exists message without the
+INFO suffix.</p>
+</dd>
+
+<dt id="opt--remove-source-files"><code>--remove-source-files</code><a href="#opt--remove-source-files" class="tgt"></a></dt><dd>
+<p>This tells rsync to remove from the sending side the files (meaning
+non-directories) that are a part of the transfer and have been successfully
+duplicated on the receiving side.</p>
+<p>Note that you should only use this option on source files that are
+quiescent. If you are using this to move files that show up in a
+particular directory over to another host, make sure that the finished
+files get renamed into the source directory, not directly written into it,
+so that rsync can't possibly transfer a file that is not yet fully written.
+If you can't first write the files into a different directory, you should
+use a naming idiom that lets rsync avoid transferring files that are not
+yet finished (e.g. name the file &quot;foo.new&quot; when it is written, rename it to
+&quot;foo&quot; when it is done, and then use the option <a href="#opt--exclude"><code>--exclude='*.new'</code></a>
+for the rsync transfer).</p>
+<p>Starting with 3.1.0, rsync will skip the sender-side removal (and output an
+error) if the file's size or modify time has not stayed unchanged.</p>
+<p>Starting with 3.2.6, a local rsync copy will ensure that the sender does
+not remove a file the receiver just verified, such as when the user
+accidentally makes the source and destination directory the same path.</p>
+</dd>
+
+<dt id="opt--delete"><code>--delete</code><a href="#opt--delete" class="tgt"></a></dt><dd>
+<p>This tells rsync to delete extraneous files from the receiving side (ones
+that aren't on the sending side), but only for the directories that are
+being synchronized. You must have asked rsync to send the whole directory
+(e.g. &quot;<code>dir</code>&quot; or &quot;<code>dir/</code>&quot;) without using a wildcard for the directory's
+contents (e.g. &quot;<code>dir/*</code>&quot;) since the wildcard is expanded by the shell and
+rsync thus gets a request to transfer individual files, not the files'
+parent directory. Files that are excluded from the transfer are also
+excluded from being deleted unless you use the <a href="#opt--delete-excluded"><code>--delete-excluded</code></a>
+option or mark the rules as only matching on the sending side (see the
+include/exclude modifiers in the <a href="#FILTER_RULES">FILTER RULES</a> section).</p>
+<p>Prior to rsync 2.6.7, this option would have no effect unless
+<a href="#opt--recursive"><code>--recursive</code></a> was enabled. Beginning with 2.6.7, deletions will
+also occur when <a href="#opt--dirs"><code>--dirs</code></a> (<code>-d</code>) is enabled, but only for
+directories whose contents are being copied.</p>
+<p>This option can be dangerous if used incorrectly! It is a very good idea to
+first try a run using the <a href="#opt--dry-run"><code>--dry-run</code></a> (<code>-n</code>) option to see what
+files are going to be deleted.</p>
+<p>If the sending side detects any I/O errors, then the deletion of any files
+at the destination will be automatically disabled. This is to prevent
+temporary filesystem failures (such as NFS errors) on the sending side from
+causing a massive deletion of files on the destination. You can override
+this with the <a href="#opt--ignore-errors"><code>--ignore-errors</code></a> option.</p>
+<p>The <code>--delete</code> option may be combined with one of the -&#8288;-&#8288;delete-WHEN options
+without conflict, as well as <a href="#opt--delete-excluded"><code>--delete-excluded</code></a>. However, if none
+of the <code>--delete-WHEN</code> options are specified, rsync will choose the
+<a href="#opt--delete-during"><code>--delete-during</code></a> algorithm when talking to rsync 3.0.0 or newer,
+or the <a href="#opt--delete-before"><code>--delete-before</code></a> algorithm when talking to an older rsync.
+See also <a href="#opt--delete-delay"><code>--delete-delay</code></a> and <a href="#opt--delete-after"><code>--delete-after</code></a>.</p>
+</dd>
+
+<dt id="opt--delete-before"><code>--delete-before</code><a href="#opt--delete-before" class="tgt"></a></dt><dd>
+<p>Request that the file-deletions on the receiving side be done before the
+transfer starts. See <a href="#opt--delete"><code>--delete</code></a> (which is implied) for more
+details on file-deletion.</p>
+<p>Deleting before the transfer is helpful if the filesystem is tight for
+space and removing extraneous files would help to make the transfer
+possible. However, it does introduce a delay before the start of the
+transfer, and this delay might cause the transfer to timeout (if
+<a href="#opt--timeout"><code>--timeout</code></a> was specified). It also forces rsync to use the old,
+non-incremental recursion algorithm that requires rsync to scan all the
+files in the transfer into memory at once (see <a href="#opt--recursive"><code>--recursive</code></a>).</p>
+</dd>
+
+<span id="opt--del"></span><dt id="opt--delete-during"><code>--delete-during</code>, <code>--del</code><a href="#opt--delete-during" class="tgt"></a></dt><dd>
+<p>Request that the file-deletions on the receiving side be done incrementally
+as the transfer happens. The per-directory delete scan is done right
+before each directory is checked for updates, so it behaves like a more
+efficient <a href="#opt--delete-before"><code>--delete-before</code></a>, including doing the deletions prior to
+any per-directory filter files being updated. This option was first added
+in rsync version 2.6.4. See <a href="#opt--delete"><code>--delete</code></a> (which is implied) for more
+details on file-deletion.</p>
+</dd>
+
+<dt id="opt--delete-delay"><code>--delete-delay</code><a href="#opt--delete-delay" class="tgt"></a></dt><dd>
+<p>Request that the file-deletions on the receiving side be computed during
+the transfer (like <a href="#opt--delete-during"><code>--delete-during</code></a>), and then removed after the
+transfer completes. This is useful when combined with
+<a href="#opt--delay-updates"><code>--delay-updates</code></a> and/or <a href="#opt--fuzzy"><code>--fuzzy</code></a>, and is more efficient
+than using <a href="#opt--delete-after"><code>--delete-after</code></a> (but can behave differently, since
+<a href="#opt--delete-after"><code>--delete-after</code></a> computes the deletions in a separate pass after
+all updates are done). If the number of removed files overflows an
+internal buffer, a temporary file will be created on the receiving side to
+hold the names (it is removed while open, so you shouldn't see it during
+the transfer). If the creation of the temporary file fails, rsync will try
+to fall back to using <a href="#opt--delete-after"><code>--delete-after</code></a> (which it cannot do if
+<a href="#opt--recursive"><code>--recursive</code></a> is doing an incremental scan). See
+<a href="#opt--delete"><code>--delete</code></a> (which is implied) for more details on file-deletion.</p>
+</dd>
+
+<dt id="opt--delete-after"><code>--delete-after</code><a href="#opt--delete-after" class="tgt"></a></dt><dd>
+<p>Request that the file-deletions on the receiving side be done after the
+transfer has completed. This is useful if you are sending new
+per-directory merge files as a part of the transfer and you want their
+exclusions to take effect for the delete phase of the current transfer. It
+also forces rsync to use the old, non-incremental recursion algorithm that
+requires rsync to scan all the files in the transfer into memory at once
+(see <a href="#opt--recursive"><code>--recursive</code></a>). See <a href="#opt--delete"><code>--delete</code></a> (which is implied) for
+more details on file-deletion.</p>
+<p>See also the <a href="#opt--delete-delay"><code>--delete-delay</code></a> option that might be a faster choice
+for those that just want the deletions to occur at the end of the transfer.</p>
+</dd>
+
+<dt id="opt--delete-excluded"><code>--delete-excluded</code><a href="#opt--delete-excluded" class="tgt"></a></dt><dd>
+<p>This option turns any unqualified exclude/include rules into server-side
+rules that do not affect the receiver's deletions.</p>
+<p>By default, an exclude or include has both a server-side effect (to &quot;hide&quot;
+and &quot;show&quot; files when building the server's file list) and a receiver-side
+effect (to &quot;protect&quot; and &quot;risk&quot; files when deletions are occurring). Any
+rule that has no modifier to specify what sides it is executed on will be
+instead treated as if it were a server-side rule only, avoiding any
+&quot;protect&quot; effects of the rules.</p>
+<p>A rule can still apply to both sides even with this option specified if the
+rule is given both the sender &amp; receiver modifier letters (e.g., <code>-f'-sr foo'</code>). Receiver-side protect/risk rules can also be explicitly specified
+to limit the deletions. This saves you from having to edit a bunch of
+<code>-f'- foo'</code> rules into <code>-f'-s foo'</code> (aka <code>-f'H foo'</code>) rules (not to mention
+the corresponding includes).</p>
+<p>See the <a href="#FILTER_RULES">FILTER RULES</a> section for more information. See
+<a href="#opt--delete"><code>--delete</code></a> (which is implied) for more details on deletion.</p>
+</dd>
+
+<dt id="opt--ignore-missing-args"><code>--ignore-missing-args</code><a href="#opt--ignore-missing-args" class="tgt"></a></dt><dd>
+<p>When rsync is first processing the explicitly requested source files (e.g.
+command-line arguments or <a href="#opt--files-from"><code>--files-from</code></a> entries), it is normally
+an error if the file cannot be found. This option suppresses that error,
+and does not try to transfer the file. This does not affect subsequent
+vanished-file errors if a file was initially found to be present and later
+is no longer there.</p>
+</dd>
+
+<dt id="opt--delete-missing-args"><code>--delete-missing-args</code><a href="#opt--delete-missing-args" class="tgt"></a></dt><dd>
+<p>This option takes the behavior of the (implied)
+<a href="#opt--ignore-missing-args"><code>--ignore-missing-args</code></a> option a step farther: each missing arg
+will become a deletion request of the corresponding destination file on the
+receiving side (should it exist). If the destination file is a non-empty
+directory, it will only be successfully deleted if <a href="#opt--force"><code>--force</code></a> or
+<a href="#opt--delete"><code>--delete</code></a> are in effect. Other than that, this option is
+independent of any other type of delete processing.</p>
+<p>The missing source files are represented by special file-list entries which
+display as a &quot;<code>*missing</code>&quot; entry in the <a href="#opt--list-only"><code>--list-only</code></a> output.</p>
+</dd>
+
+<dt id="opt--ignore-errors"><code>--ignore-errors</code><a href="#opt--ignore-errors" class="tgt"></a></dt><dd>
+<p>Tells <a href="#opt--delete"><code>--delete</code></a> to go ahead and delete files even when there are
+I/O errors.</p>
+</dd>
+
+<dt id="opt--force"><code>--force</code><a href="#opt--force" class="tgt"></a></dt><dd>
+<p>This option tells rsync to delete a non-empty directory when it is to be
+replaced by a non-directory. This is only relevant if deletions are not
+active (see <a href="#opt--delete"><code>--delete</code></a> for details).</p>
+<p>Note for older rsync versions: <code>--force</code> used to still be required when
+using <a href="#opt--delete-after"><code>--delete-after</code></a>, and it used to be non-functional unless the
+<a href="#opt--recursive"><code>--recursive</code></a> option was also enabled.</p>
+</dd>
+
+<dt id="opt--max-delete"><code>--max-delete=NUM</code><a href="#opt--max-delete" class="tgt"></a></dt><dd>
+<p>This tells rsync not to delete more than NUM files or directories. If that
+limit is exceeded, all further deletions are skipped through the end of the
+transfer. At the end, rsync outputs a warning (including a count of the
+skipped deletions) and exits with an error code of 25 (unless some more
+important error condition also occurred).</p>
+<p>Beginning with version 3.0.0, you may specify <code>--max-delete=0</code> to be warned
+about any extraneous files in the destination without removing any of them.
+Older clients interpreted this as &quot;unlimited&quot;, so if you don't know what
+version the client is, you can use the less obvious <code>--max-delete=-1</code> as a
+backward-compatible way to specify that no deletions be allowed (though
+really old versions didn't warn when the limit was exceeded).</p>
+</dd>
+
+<dt id="opt--max-size"><code>--max-size=SIZE</code><a href="#opt--max-size" class="tgt"></a></dt><dd>
+<p>This tells rsync to avoid transferring any file that is larger than the
+specified SIZE. A numeric value can be suffixed with a string to indicate
+the numeric units or left unqualified to specify bytes. Feel free to use a
+fractional value along with the units, such as <code>--max-size=1.5m</code>.</p>
+<p>This option is a <a href="#TRANSFER_RULES">TRANSFER RULE</a>, so don't expect any
+exclude side effects.</p>
+<p>The first letter of a units string can be <code>B</code> (bytes), <code>K</code> (kilo), <code>M</code>
+(mega), <code>G</code> (giga), <code>T</code> (tera), or <code>P</code> (peta). If the string is a single
+char or has &quot;ib&quot; added to it (e.g. &quot;G&quot; or &quot;GiB&quot;) then the units are
+multiples of 1024. If you use a two-letter suffix that ends with a &quot;B&quot;
+(e.g. &quot;kb&quot;) then you get units that are multiples of 1000. The string's
+letters can be any mix of upper and lower-case that you want to use.</p>
+<p>Finally, if the string ends with either &quot;+1&quot; or &quot;-&#8288;1&quot;, it is offset by one
+byte in the indicated direction. The largest possible value is usually
+<code>8192P-1</code>.</p>
+<p>Examples: <code>--max-size=1.5mb-1</code> is 1499999 bytes, and <code>--max-size=2g+1</code> is
+2147483649 bytes.</p>
+<p>Note that rsync versions prior to 3.1.0 did not allow <code>--max-size=0</code>.</p>
+</dd>
+
+<dt id="opt--min-size"><code>--min-size=SIZE</code><a href="#opt--min-size" class="tgt"></a></dt><dd>
+<p>This tells rsync to avoid transferring any file that is smaller than the
+specified SIZE, which can help in not transferring small, junk files. See
+the <a href="#opt--max-size"><code>--max-size</code></a> option for a description of SIZE and other info.</p>
+<p>Note that rsync versions prior to 3.1.0 did not allow <code>--min-size=0</code>.</p>
+</dd>
+
+<dt id="opt--max-alloc"><code>--max-alloc=SIZE</code><a href="#opt--max-alloc" class="tgt"></a></dt><dd>
+<p>By default rsync limits an individual malloc/realloc to about 1GB in size.
+For most people this limit works just fine and prevents a protocol error
+causing rsync to request massive amounts of memory. However, if you have
+many millions of files in a transfer, a large amount of server memory, and
+you don't want to split up your transfer into multiple parts, you can
+increase the per-allocation limit to something larger and rsync will
+consume more memory.</p>
+<p>Keep in mind that this is not a limit on the total size of allocated
+memory. It is a sanity-check value for each individual allocation.</p>
+<p>See the <a href="#opt--max-size"><code>--max-size</code></a> option for a description of how SIZE can be
+specified. The default suffix if none is given is bytes.</p>
+<p>Beginning in 3.2.3, a value of 0 specifies no limit.</p>
+<p>You can set a default value using the environment variable
+<a href="#RSYNC_MAX_ALLOC"><code>RSYNC_MAX_ALLOC</code></a> using the same SIZE values as supported by this
+option. If the remote rsync doesn't understand the <code>--max-alloc</code> option,
+you can override an environmental value by specifying <code>--max-alloc=1g</code>,
+which will make rsync avoid sending the option to the remote side (because
+&quot;1G&quot; is the default).</p>
+</dd>
+
+<span id="opt-B"></span><dt id="opt--block-size"><code>--block-size=SIZE</code>, <code>-B</code><a href="#opt--block-size" class="tgt"></a></dt><dd>
+<p>This forces the block size used in rsync's delta-transfer algorithm to a
+fixed value. It is normally selected based on the size of each file being
+updated. See the technical report for details.</p>
+<p>Beginning in 3.2.3 the SIZE can be specified with a suffix as detailed in
+the <a href="#opt--max-size"><code>--max-size</code></a> option. Older versions only accepted a byte count.</p>
+</dd>
+
+<span id="opt-e"></span><dt id="opt--rsh"><code>--rsh=COMMAND</code>, <code>-e</code><a href="#opt--rsh" class="tgt"></a></dt><dd>
+<p>This option allows you to choose an alternative remote shell program to use
+for communication between the local and remote copies of rsync. Typically,
+rsync is configured to use ssh by default, but you may prefer to use rsh on
+a local network.</p>
+<p>If this option is used with <code>[user@]host::module/path</code>, then the remote
+shell <u>COMMAND</u> will be used to run an rsync daemon on the remote host, and
+all data will be transmitted through that remote shell connection, rather
+than through a direct socket connection to a running rsync daemon on the
+remote host. See the <a href="#USING_RSYNC-DAEMON_FEATURES_VIA_A_REMOTE-SHELL_CONNECTION">USING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL
+CONNECTION</a> section above.</p>
+<p>Beginning with rsync 3.2.0, the <a href="#RSYNC_PORT"><code>RSYNC_PORT</code></a> environment variable will
+be set when a daemon connection is being made via a remote-shell
+connection. It is set to 0 if the default daemon port is being assumed, or
+it is set to the value of the rsync port that was specified via either the
+<a href="#opt--port"><code>--port</code></a> option or a non-empty port value in an <code>rsync://</code> URL.
+This allows the script to discern if a non-default port is being requested,
+allowing for things such as an SSL or stunnel helper script to connect to a
+default or alternate port.</p>
+<p>Command-line arguments are permitted in COMMAND provided that COMMAND is
+presented to rsync as a single argument. You must use spaces (not tabs or
+other whitespace) to separate the command and args from each other, and you
+can use single- and/or double-quotes to preserve spaces in an argument (but
+not backslashes). Note that doubling a single-quote inside a single-quoted
+string gives you a single-quote; likewise for double-quotes (though you
+need to pay attention to which quotes your shell is parsing and which
+quotes rsync is parsing). Some examples:</p>
+<blockquote>
+<pre><code>-e 'ssh -p 2234'
+-e 'ssh -o &quot;ProxyCommand nohup ssh firewall nc -w1 %h %p&quot;'
+</code></pre>
+</blockquote>
+<p>(Note that ssh users can alternately customize site-specific connect
+options in their .ssh/config file.)</p>
+<p>You can also choose the remote shell program using the <a href="#RSYNC_RSH"><code>RSYNC_RSH</code></a>
+environment variable, which accepts the same range of values as <code>-e</code>.</p>
+<p>See also the <a href="#opt--blocking-io"><code>--blocking-io</code></a> option which is affected by this
+option.</p>
+</dd>
+
+<dt id="opt--rsync-path"><code>--rsync-path=PROGRAM</code><a href="#opt--rsync-path" class="tgt"></a></dt><dd>
+<p>Use this to specify what program is to be run on the remote machine to
+start-up rsync. Often used when rsync is not in the default remote-shell's
+path (e.g. <code>--rsync-path=/usr/local/bin/rsync</code>). Note that PROGRAM is run
+with the help of a shell, so it can be any program, script, or command
+sequence you'd care to run, so long as it does not corrupt the standard-in
+&amp; standard-out that rsync is using to communicate.</p>
+<p>One tricky example is to set a different default directory on the remote
+machine for use with the <a href="#opt--relative"><code>--relative</code></a> option. For instance:</p>
+<blockquote>
+<pre><code>rsync -avR --rsync-path=&quot;cd /a/b &amp;&amp; rsync&quot; host:c/d /e/
+</code></pre>
+</blockquote>
+</dd>
+
+<span id="opt-M"></span><dt id="opt--remote-option"><code>--remote-option=OPTION</code>, <code>-M</code><a href="#opt--remote-option" class="tgt"></a></dt><dd>
+<p>This option is used for more advanced situations where you want certain
+effects to be limited to one side of the transfer only. For instance, if
+you want to pass <a href="#opt--log-file"><code>--log-file=FILE</code></a> and <a href="#opt--fake-super"><code>--fake-super</code></a> to
+the remote system, specify it like this:</p>
+<blockquote>
+<pre><code>rsync -av -M --log-file=foo -M--fake-super src/ dest/
+</code></pre>
+</blockquote>
+<p>If you want to have an option affect only the local side of a transfer when
+it normally affects both sides, send its negation to the remote side. Like
+this:</p>
+<blockquote>
+<pre><code>rsync -av -x -M--no-x src/ dest/
+</code></pre>
+</blockquote>
+<p>Be cautious using this, as it is possible to toggle an option that will
+cause rsync to have a different idea about what data to expect next over
+the socket, and that will make it fail in a cryptic fashion.</p>
+<p>Note that you should use a separate <code>-M</code> option for each remote option you
+want to pass. On older rsync versions, the presence of any spaces in the
+remote-option arg could cause it to be split into separate remote args, but
+this requires the use of <a href="#opt--old-args"><code>--old-args</code></a> in a modern rsync.</p>
+<p>When performing a local transfer, the &quot;local&quot; side is the sender and the
+&quot;remote&quot; side is the receiver.</p>
+<p>Note some versions of the popt option-parsing library have a bug in them
+that prevents you from using an adjacent arg with an equal in it next to a
+short option letter (e.g. <code>-M--log-file=/tmp/foo</code>). If this bug affects
+your version of popt, you can use the version of popt that is included with
+rsync.</p>
+</dd>
+
+<span id="opt-C"></span><dt id="opt--cvs-exclude"><code>--cvs-exclude</code>, <code>-C</code><a href="#opt--cvs-exclude" class="tgt"></a></dt><dd>
+<p>This is a useful shorthand for excluding a broad range of files that you
+often don't want to transfer between systems. It uses a similar algorithm
+to CVS to determine if a file should be ignored.</p>
+<p>The exclude list is initialized to exclude the following items (these
+initial items are marked as perishable&nbsp;-&#8288;-&#8288; see the <a href="#FILTER_RULES">FILTER RULES</a>
+section):</p>
+<blockquote>
+<p><code>RCS</code>
+<code>SCCS</code>
+<code>CVS</code>
+<code>CVS.adm</code>
+<code>RCSLOG</code>
+<code>cvslog.*</code>
+<code>tags</code>
+<code>TAGS</code>
+<code>.make.state</code>
+<code>.nse_depinfo</code>
+<code>*~</code>
+<code>#*</code>
+<code>.#*</code>
+<code>,*</code>
+<code>_$*</code>
+<code>*$</code>
+<code>*.old</code>
+<code>*.bak</code>
+<code>*.BAK</code>
+<code>*.orig</code>
+<code>*.rej</code>
+<code>.del-*</code>
+<code>*.a</code>
+<code>*.olb</code>
+<code>*.o</code>
+<code>*.obj</code>
+<code>*.so</code>
+<code>*.exe</code>
+<code>*.Z</code>
+<code>*.elc</code>
+<code>*.ln</code>
+<code>core</code>
+<code>.svn/</code>
+<code>.git/</code>
+<code>.hg/</code>
+<code>.bzr/</code></p>
+</blockquote>
+<p>then, files listed in a $HOME/.cvsignore are added to the list and any
+files listed in the CVSIGNORE environment variable (all cvsignore names are
+delimited by whitespace).</p>
+<p>Finally, any file is ignored if it is in the same directory as a .cvsignore
+file and matches one of the patterns listed therein. Unlike rsync's
+filter/exclude files, these patterns are split on whitespace. See the
+<strong>cvs</strong>(1) manual for more information.</p>
+<p>If you're combining <code>-C</code> with your own <a href="#opt--filter"><code>--filter</code></a> rules, you should
+note that these CVS excludes are appended at the end of your own rules,
+regardless of where the <code>-C</code> was placed on the command-line. This makes
+them a lower priority than any rules you specified explicitly. If you want
+to control where these CVS excludes get inserted into your filter rules,
+you should omit the <code>-C</code> as a command-line option and use a combination of
+<a href="#opt--filter"><code>--filter=:C</code></a> and <a href="#opt--filter"><code>--filter=-C</code></a> (either on your
+command-line or by putting the &quot;:C&quot; and &quot;-&#8288;C&quot; rules into a filter file with
+your other rules). The first option turns on the per-directory scanning
+for the .cvsignore file. The second option does a one-time import of the
+CVS excludes mentioned above.</p>
+</dd>
+
+<span id="opt-f"></span><dt id="opt--filter"><code>--filter=RULE</code>, <code>-f</code><a href="#opt--filter" class="tgt"></a></dt><dd>
+<p>This option allows you to add rules to selectively exclude certain files
+from the list of files to be transferred. This is most useful in
+combination with a recursive transfer.</p>
+<p>You may use as many <code>--filter</code> options on the command line as you like to
+build up the list of files to exclude. If the filter contains whitespace,
+be sure to quote it so that the shell gives the rule to rsync as a single
+argument. The text below also mentions that you can use an underscore to
+replace the space that separates a rule from its arg.</p>
+<p>See the <a href="#FILTER_RULES">FILTER RULES</a> section for detailed information on this option.</p>
+</dd>
+
+<dt id="opt-F"><code>-F</code><a href="#opt-F" class="tgt"></a></dt><dd>
+<p>The <code>-F</code> option is a shorthand for adding two <a href="#opt--filter"><code>--filter</code></a> rules to
+your command. The first time it is used is a shorthand for this rule:</p>
+<blockquote>
+<pre><code>--filter='dir-merge /.rsync-filter'
+</code></pre>
+</blockquote>
+<p>This tells rsync to look for per-directory .rsync-filter files that have
+been sprinkled through the hierarchy and use their rules to filter the
+files in the transfer. If <code>-F</code> is repeated, it is a shorthand for this
+rule:</p>
+<blockquote>
+<pre><code>--filter='exclude .rsync-filter'
+</code></pre>
+</blockquote>
+<p>This filters out the .rsync-filter files themselves from the transfer.</p>
+<p>See the <a href="#FILTER_RULES">FILTER RULES</a> section for detailed information on how these
+options work.</p>
+</dd>
+
+<dt id="opt--exclude"><code>--exclude=PATTERN</code><a href="#opt--exclude" class="tgt"></a></dt><dd>
+<p>This option is a simplified form of the <a href="#opt--filter"><code>--filter</code></a> option that
+specifies an exclude rule and does not allow the full rule-parsing syntax
+of normal filter rules. This is equivalent to specifying <code>-f'- PATTERN'</code>.</p>
+<p>See the <a href="#FILTER_RULES">FILTER RULES</a> section for detailed information on this option.</p>
+</dd>
+
+<dt id="opt--exclude-from"><code>--exclude-from=FILE</code><a href="#opt--exclude-from" class="tgt"></a></dt><dd>
+<p>This option is related to the <a href="#opt--exclude"><code>--exclude</code></a> option, but it specifies
+a FILE that contains exclude patterns (one per line). Blank lines in the
+file are ignored, as are whole-line comments that start with '<code>;</code>' or '<code>#</code>'
+(filename rules that contain those characters are unaffected).</p>
+<p>If a line begins with &quot;<code>- </code>&quot; (dash, space) or &quot;<code>+ </code>&quot; (plus, space), then
+the type of rule is being explicitly specified as an exclude or an include
+(respectively). Any rules without such a prefix are taken to be an exclude.</p>
+<p>If a line consists of just &quot;<code>!</code>&quot;, then the current filter rules are cleared
+before adding any further rules.</p>
+<p>If <u>FILE</u> is '<code>-</code>', the list will be read from standard input.</p>
+</dd>
+
+<dt id="opt--include"><code>--include=PATTERN</code><a href="#opt--include" class="tgt"></a></dt><dd>
+<p>This option is a simplified form of the <a href="#opt--filter"><code>--filter</code></a> option that
+specifies an include rule and does not allow the full rule-parsing syntax
+of normal filter rules. This is equivalent to specifying <code>-f'+ PATTERN'</code>.</p>
+<p>See the <a href="#FILTER_RULES">FILTER RULES</a> section for detailed information on this option.</p>
+</dd>
+
+<dt id="opt--include-from"><code>--include-from=FILE</code><a href="#opt--include-from" class="tgt"></a></dt><dd>
+<p>This option is related to the <a href="#opt--include"><code>--include</code></a> option, but it specifies
+a FILE that contains include patterns (one per line). Blank lines in the
+file are ignored, as are whole-line comments that start with '<code>;</code>' or '<code>#</code>'
+(filename rules that contain those characters are unaffected).</p>
+<p>If a line begins with &quot;<code>- </code>&quot; (dash, space) or &quot;<code>+ </code>&quot; (plus, space), then
+the type of rule is being explicitly specified as an exclude or an include
+(respectively). Any rules without such a prefix are taken to be an include.</p>
+<p>If a line consists of just &quot;<code>!</code>&quot;, then the current filter rules are cleared
+before adding any further rules.</p>
+<p>If <u>FILE</u> is '<code>-</code>', the list will be read from standard input.</p>
+</dd>
+
+<dt id="opt--files-from"><code>--files-from=FILE</code><a href="#opt--files-from" class="tgt"></a></dt><dd>
+<p>Using this option allows you to specify the exact list of files to transfer
+(as read from the specified FILE or '<code>-</code>' for standard input). It also
+tweaks the default behavior of rsync to make transferring just the
+specified files and directories easier:</p>
+<ul>
+<li>The <a href="#opt--relative"><code>--relative</code></a> (<code>-R</code>) option is implied, which preserves the
+path information that is specified for each item in the file (use
+<code>--no-relative</code> or <code>--no-R</code> if you want to turn that off).</li>
+<li>The <a href="#opt--dirs"><code>--dirs</code></a> (<code>-d</code>) option is implied, which will create
+directories specified in the list on the destination rather than noisily
+skipping them (use <code>--no-dirs</code> or <code>--no-d</code> if you want to turn that off).</li>
+<li>The <a href="#opt--archive"><code>--archive</code></a> (<code>-a</code>) option's behavior does not imply
+<a href="#opt--recursive"><code>--recursive</code></a> (<code>-r</code>), so specify it explicitly, if you want it.</li>
+<li>These side-effects change the default state of rsync, so the position of
+the <code>--files-from</code> option on the command-line has no bearing on how other
+options are parsed (e.g. <a href="#opt-a"><code>-a</code></a> works the same before or after
+<code>--files-from</code>, as does <code>--no-R</code> and all other options).</li>
+</ul>
+<p>The filenames that are read from the FILE are all relative to the source
+dir&nbsp;-&#8288;-&#8288; any leading slashes are removed and no &quot;..&quot; references are allowed
+to go higher than the source dir. For example, take this command:</p>
+<blockquote>
+<pre><code>rsync -a --files-from=/tmp/foo /usr remote:/backup
+</code></pre>
+</blockquote>
+<p>If /tmp/foo contains the string &quot;bin&quot; (or even &quot;/bin&quot;), the /usr/bin
+directory will be created as /backup/bin on the remote host. If it
+contains &quot;bin/&quot; (note the trailing slash), the immediate contents of the
+directory would also be sent (without needing to be explicitly mentioned in
+the file&nbsp;-&#8288;-&#8288; this began in version 2.6.4). In both cases, if the
+<a href="#opt-r"><code>-r</code></a> option was enabled, that dir's entire hierarchy would also be
+transferred (keep in mind that <a href="#opt-r"><code>-r</code></a> needs to be specified
+explicitly with <code>--files-from</code>, since it is not implied by <a href="#opt-a"><code>-a</code></a>.
+Also note that the effect of the (enabled by default) <a href="#opt-r"><code>-r</code></a> option
+is to duplicate only the path info that is read from the file&nbsp;-&#8288;-&#8288; it does
+not force the duplication of the source-spec path (/usr in this case).</p>
+<p>In addition, the <code>--files-from</code> file can be read from the remote host
+instead of the local host if you specify a &quot;host:&quot; in front of the file
+(the host must match one end of the transfer). As a short-cut, you can
+specify just a prefix of &quot;:&quot; to mean &quot;use the remote end of the transfer&quot;.
+For example:</p>
+<blockquote>
+<pre><code>rsync -a --files-from=:/path/file-list src:/ /tmp/copy
+</code></pre>
+</blockquote>
+<p>This would copy all the files specified in the /path/file-list file that
+was located on the remote &quot;src&quot; host.</p>
+<p>If the <a href="#opt--iconv"><code>--iconv</code></a> and <a href="#opt--secluded-args"><code>--secluded-args</code></a> options are specified
+and the <code>--files-from</code> filenames are being sent from one host to another,
+the filenames will be translated from the sending host's charset to the
+receiving host's charset.</p>
+<p>NOTE: sorting the list of files in the <code>--files-from</code> input helps rsync to
+be more efficient, as it will avoid re-visiting the path elements that are
+shared between adjacent entries. If the input is not sorted, some path
+elements (implied directories) may end up being scanned multiple times, and
+rsync will eventually unduplicate them after they get turned into file-list
+elements.</p>
+</dd>
+
+<span id="opt-0"></span><dt id="opt--from0"><code>--from0</code>, <code>-0</code><a href="#opt--from0" class="tgt"></a></dt><dd>
+<p>This tells rsync that the rules/filenames it reads from a file are
+terminated by a null ('\0') character, not a NL, CR, or CR+LF. This
+affects <a href="#opt--exclude-from"><code>--exclude-from</code></a>, <a href="#opt--include-from"><code>--include-from</code></a>,
+<a href="#opt--files-from"><code>--files-from</code></a>, and any merged files specified in a
+<a href="#opt--filter"><code>--filter</code></a> rule. It does not affect <a href="#opt--cvs-exclude"><code>--cvs-exclude</code></a> (since
+all names read from a .cvsignore file are split on whitespace).</p>
+</dd>
+
+<dt id="opt--old-args"><code>--old-args</code><a href="#opt--old-args" class="tgt"></a></dt><dd>
+<p>This option tells rsync to stop trying to protect the arg values on the
+remote side from unintended word-splitting or other misinterpretation.
+It also allows the client to treat an empty arg as a &quot;.&quot; instead of
+generating an error.</p>
+<p>The default in a modern rsync is for &quot;shell-active&quot; characters (including
+spaces) to be backslash-escaped in the args that are sent to the remote
+shell. The wildcard characters <code>*</code>, <code>?</code>, <code>[</code>, &amp; <code>]</code> are not escaped in
+filename args (allowing them to expand into multiple filenames) while being
+protected in option args, such as <a href="#opt--usermap"><code>--usermap</code></a>.</p>
+<p>If you have a script that wants to use old-style arg splitting in its
+filenames, specify this option once. If the remote shell has a problem
+with any backslash escapes at all, specify this option twice.</p>
+<p>You may also control this setting via the <a href="#RSYNC_OLD_ARGS"><code>RSYNC_OLD_ARGS</code></a> environment
+variable. If it has the value &quot;1&quot;, rsync will default to a single-option
+setting. If it has the value &quot;2&quot; (or more), rsync will default to a
+repeated-option setting. If it is &quot;0&quot;, you'll get the default escaping
+behavior. The environment is always overridden by manually specified
+positive or negative options (the negative is <code>--no-old-args</code>).</p>
+<p>Note that this option also disables the extra safety check added in 3.2.5
+that ensures that a remote sender isn't including extra top-level items in
+the file-list that you didn't request. This side-effect is necessary
+because we can't know for sure what names to expect when the remote shell
+is interpreting the args.</p>
+<p>This option conflicts with the <a href="#opt--secluded-args"><code>--secluded-args</code></a> option.</p>
+</dd>
+
+<span id="opt-s"></span><dt id="opt--secluded-args"><code>--secluded-args</code>, <code>-s</code><a href="#opt--secluded-args" class="tgt"></a></dt><dd>
+<p>This option sends all filenames and most options to the remote rsync via
+the protocol (not the remote shell command line) which avoids letting the
+remote shell modify them. Wildcards are expanded on the remote host by
+rsync instead of a shell.</p>
+<p>This is similar to the default backslash-escaping of args that was added
+in 3.2.4 (see <a href="#opt--old-args"><code>--old-args</code></a>) in that it prevents things like space
+splitting and unwanted special-character side-effects. However, it has the
+drawbacks of being incompatible with older rsync versions (prior to 3.0.0)
+and of being refused by restricted shells that want to be able to inspect
+all the option values for safety.</p>
+<p>This option is useful for those times that you need the argument's
+character set to be converted for the remote host, if the remote shell is
+incompatible with the default backslash-escpaing method, or there is some
+other reason that you want the majority of the options and arguments to
+bypass the command-line of the remote shell.</p>
+<p>If you combine this option with <a href="#opt--iconv"><code>--iconv</code></a>, the args related to the
+remote side will be translated from the local to the remote character-set.
+The translation happens before wild-cards are expanded. See also the
+<a href="#opt--files-from"><code>--files-from</code></a> option.</p>
+<p>You may also control this setting via the <a href="#RSYNC_PROTECT_ARGS"><code>RSYNC_PROTECT_ARGS</code></a>
+environment variable. If it has a non-zero value, this setting will be
+enabled by default, otherwise it will be disabled by default. Either state
+is overridden by a manually specified positive or negative version of this
+option (note that <code>--no-s</code> and <code>--no-secluded-args</code> are the negative
+versions). This environment variable is also superseded by a non-zero
+<a href="#RSYNC_OLD_ARGS"><code>RSYNC_OLD_ARGS</code></a> export.</p>
+<p>This option conflicts with the <a href="#opt--old-args"><code>--old-args</code></a> option.</p>
+<p>This option used to be called <code>--protect-args</code> (before 3.2.6) and that
+older name can still be used (though specifying it as <code>-s</code> is always the
+easiest and most compatible choice).</p>
+</dd>
+
+<dt id="opt--trust-sender"><code>--trust-sender</code><a href="#opt--trust-sender" class="tgt"></a></dt><dd>
+<p>This option disables two extra validation checks that a local client
+performs on the file list generated by a remote sender. This option should
+only be used if you trust the sender to not put something malicious in the
+file list (something that could possibly be done via a modified rsync, a
+modified shell, or some other similar manipulation).</p>
+<p>Normally, the rsync client (as of version 3.2.5) runs two extra validation
+checks when pulling files from a remote rsync:</p>
+<ul>
+<li>It verifies that additional arg items didn't get added at the top of the
+transfer.</li>
+<li>It verifies that none of the items in the file list are names that should
+have been excluded (if filter rules were specified).</li>
+</ul>
+<p>Note that various options can turn off one or both of these checks if the
+option interferes with the validation. For instance:</p>
+<ul>
+<li>Using a per-directory filter file reads filter rules that only the server
+knows about, so the filter checking is disabled.</li>
+<li>Using the <a href="#opt--old-args"><code>--old-args</code></a> option allows the sender to manipulate the
+requested args, so the arg checking is disabled.</li>
+<li>Reading the files-from list from the server side means that the client
+doesn't know the arg list, so the arg checking is disabled.</li>
+<li>Using <a href="#opt--read-batch"><code>--read-batch</code></a> disables both checks since the batch file's
+contents will have been verified when it was created.</li>
+</ul>
+<p>This option may help an under-powered client server if the extra pattern
+matching is slowing things down on a huge transfer. It can also be used to
+work around a currently-unknown bug in the verification logic for a transfer
+from a trusted sender.</p>
+<p>When using this option it is a good idea to specify a dedicated destination
+directory, as discussed in the <a href="#MULTI-HOST_SECURITY">MULTI-HOST SECURITY</a> section.</p>
+</dd>
+
+<dt id="opt--copy-as"><code>--copy-as=USER[:GROUP]</code><a href="#opt--copy-as" class="tgt"></a></dt><dd>
+<p>This option instructs rsync to use the USER and (if specified after a
+colon) the GROUP for the copy operations. This only works if the user that
+is running rsync has the ability to change users. If the group is not
+specified then the user's default groups are used.</p>
+<p>This option can help to reduce the risk of an rsync being run as root into
+or out of a directory that might have live changes happening to it and you
+want to make sure that root-level read or write actions of system files are
+not possible. While you could alternatively run all of rsync as the
+specified user, sometimes you need the root-level host-access credentials
+to be used, so this allows rsync to drop root for the copying part of the
+operation after the remote-shell or daemon connection is established.</p>
+<p>The option only affects one side of the transfer unless the transfer is
+local, in which case it affects both sides. Use the
+<a href="#opt--remote-option"><code>--remote-option</code></a> to affect the remote side, such as
+<code>-M--copy-as=joe</code>. For a local transfer, the lsh (or lsh.sh) support file
+provides a local-shell helper script that can be used to allow a
+&quot;localhost:&quot; or &quot;lh:&quot; host-spec to be specified without needing to setup
+any remote shells, allowing you to specify remote options that affect the
+side of the transfer that is using the host-spec (and using hostname &quot;lh&quot;
+avoids the overriding of the remote directory to the user's home dir).</p>
+<p>For example, the following rsync writes the local files as user &quot;joe&quot;:</p>
+<blockquote>
+<pre><code>sudo rsync -aiv --copy-as=joe host1:backups/joe/ /home/joe/
+</code></pre>
+</blockquote>
+<p>This makes all files owned by user &quot;joe&quot;, limits the groups to those that
+are available to that user, and makes it impossible for the joe user to do
+a timed exploit of the path to induce a change to a file that the joe user
+has no permissions to change.</p>
+<p>The following command does a local copy into the &quot;dest/&quot; dir as user &quot;joe&quot;
+(assuming you've installed support/lsh into a dir on your $PATH):</p>
+<blockquote>
+<pre><code>sudo rsync -aive lsh -M--copy-as=joe src/ lh:dest/
+</code></pre>
+</blockquote>
+</dd>
+
+<span id="opt-T"></span><dt id="opt--temp-dir"><code>--temp-dir=DIR</code>, <code>-T</code><a href="#opt--temp-dir" class="tgt"></a></dt><dd>
+<p>This option instructs rsync to use DIR as a scratch directory when creating
+temporary copies of the files transferred on the receiving side. The
+default behavior is to create each temporary file in the same directory as
+the associated destination file. Beginning with rsync 3.1.1, the temp-file
+names inside the specified DIR will not be prefixed with an extra dot
+(though they will still have a random suffix added).</p>
+<p>This option is most often used when the receiving disk partition does not
+have enough free space to hold a copy of the largest file in the transfer.
+In this case (i.e. when the scratch directory is on a different disk
+partition), rsync will not be able to rename each received temporary file
+over the top of the associated destination file, but instead must copy it
+into place. Rsync does this by copying the file over the top of the
+destination file, which means that the destination file will contain
+truncated data during this copy. If this were not done this way (even if
+the destination file were first removed, the data locally copied to a
+temporary file in the destination directory, and then renamed into place)
+it would be possible for the old file to continue taking up disk space (if
+someone had it open), and thus there might not be enough room to fit the
+new version on the disk at the same time.</p>
+<p>If you are using this option for reasons other than a shortage of disk
+space, you may wish to combine it with the <a href="#opt--delay-updates"><code>--delay-updates</code></a>
+option, which will ensure that all copied files get put into subdirectories
+in the destination hierarchy, awaiting the end of the transfer. If you
+don't have enough room to duplicate all the arriving files on the
+destination partition, another way to tell rsync that you aren't overly
+concerned about disk space is to use the <a href="#opt--partial-dir"><code>--partial-dir</code></a> option
+with a relative path; because this tells rsync that it is OK to stash off a
+copy of a single file in a subdir in the destination hierarchy, rsync will
+use the partial-dir as a staging area to bring over the copied file, and
+then rename it into place from there. (Specifying a <a href="#opt--partial-dir"><code>--partial-dir</code></a>
+with an absolute path does not have this side-effect.)</p>
+</dd>
+
+<span id="opt-y"></span><dt id="opt--fuzzy"><code>--fuzzy</code>, <code>-y</code><a href="#opt--fuzzy" class="tgt"></a></dt><dd>
+<p>This option tells rsync that it should look for a basis file for any
+destination file that is missing. The current algorithm looks in the same
+directory as the destination file for either a file that has an identical
+size and modified-time, or a similarly-named file. If found, rsync uses
+the fuzzy basis file to try to speed up the transfer.</p>
+<p>If the option is repeated, the fuzzy scan will also be done in any matching
+alternate destination directories that are specified via
+<a href="#opt--compare-dest"><code>--compare-dest</code></a>, <a href="#opt--copy-dest"><code>--copy-dest</code></a>, or <a href="#opt--link-dest"><code>--link-dest</code></a>.</p>
+<p>Note that the use of the <a href="#opt--delete"><code>--delete</code></a> option might get rid of any
+potential fuzzy-match files, so either use <a href="#opt--delete-after"><code>--delete-after</code></a> or
+specify some filename exclusions if you need to prevent this.</p>
+</dd>
+
+<dt id="opt--compare-dest"><code>--compare-dest=DIR</code><a href="#opt--compare-dest" class="tgt"></a></dt><dd>
+<p>This option instructs rsync to use <u>DIR</u> on the destination machine as an
+additional hierarchy to compare destination files against doing transfers
+(if the files are missing in the destination directory). If a file is
+found in <u>DIR</u> that is identical to the sender's file, the file will NOT be
+transferred to the destination directory. This is useful for creating a
+sparse backup of just files that have changed from an earlier backup. This
+option is typically used to copy into an empty (or newly created)
+directory.</p>
+<p>Beginning in version 2.6.4, multiple <code>--compare-dest</code> directories may be
+provided, which will cause rsync to search the list in the order specified
+for an exact match. If a match is found that differs only in attributes, a
+local copy is made and the attributes updated. If a match is not found, a
+basis file from one of the <u>DIRs</u> will be selected to try to speed up the
+transfer.</p>
+<p>If <u>DIR</u> is a relative path, it is relative to the destination directory.
+See also <a href="#opt--copy-dest"><code>--copy-dest</code></a> and <a href="#opt--link-dest"><code>--link-dest</code></a>.</p>
+<p>NOTE: beginning with version 3.1.0, rsync will remove a file from a
+non-empty destination hierarchy if an exact match is found in one of the
+compare-dest hierarchies (making the end result more closely match a fresh
+copy).</p>
+</dd>
+
+<dt id="opt--copy-dest"><code>--copy-dest=DIR</code><a href="#opt--copy-dest" class="tgt"></a></dt><dd>
+<p>This option behaves like <a href="#opt--compare-dest"><code>--compare-dest</code></a>, but rsync will also copy
+unchanged files found in <u>DIR</u> to the destination directory using a local
+copy. This is useful for doing transfers to a new destination while
+leaving existing files intact, and then doing a flash-cutover when all
+files have been successfully transferred.</p>
+<p>Multiple <code>--copy-dest</code> directories may be provided, which will cause rsync
+to search the list in the order specified for an unchanged file. If a
+match is not found, a basis file from one of the <u>DIRs</u> will be selected to
+try to speed up the transfer.</p>
+<p>If <u>DIR</u> is a relative path, it is relative to the destination directory.
+See also <a href="#opt--compare-dest"><code>--compare-dest</code></a> and <a href="#opt--link-dest"><code>--link-dest</code></a>.</p>
+</dd>
+
+<dt id="opt--link-dest"><code>--link-dest=DIR</code><a href="#opt--link-dest" class="tgt"></a></dt><dd>
+<p>This option behaves like <a href="#opt--copy-dest"><code>--copy-dest</code></a>, but unchanged files are
+hard linked from <u>DIR</u> to the destination directory. The files must be
+identical in all preserved attributes (e.g. permissions, possibly
+ownership) in order for the files to be linked together. An example:</p>
+<blockquote>
+<pre><code>rsync -av --link-dest=$PWD/prior_dir host:src_dir/ new_dir/
+</code></pre>
+</blockquote>
+<p>If files aren't linking, double-check their attributes. Also check if
+some attributes are getting forced outside of rsync's control, such a mount
+option that squishes root to a single user, or mounts a removable drive
+with generic ownership (such as OS X's &quot;Ignore ownership on this volume&quot;
+option).</p>
+<p>Beginning in version 2.6.4, multiple <code>--link-dest</code> directories may be
+provided, which will cause rsync to search the list in the order specified
+for an exact match (there is a limit of 20 such directories). If a match
+is found that differs only in attributes, a local copy is made and the
+attributes updated. If a match is not found, a basis file from one of the
+<u>DIRs</u> will be selected to try to speed up the transfer.</p>
+<p>This option works best when copying into an empty destination hierarchy, as
+existing files may get their attributes tweaked, and that can affect
+alternate destination files via hard-links. Also, itemizing of changes can
+get a bit muddled. Note that prior to version 3.1.0, an
+alternate-directory exact match would never be found (nor linked into the
+destination) when a destination file already exists.</p>
+<p>Note that if you combine this option with <a href="#opt--ignore-times"><code>--ignore-times</code></a>, rsync will not
+link any files together because it only links identical files together as a
+substitute for transferring the file, never as an additional check after
+the file is updated.</p>
+<p>If <u>DIR</u> is a relative path, it is relative to the destination directory.
+See also <a href="#opt--compare-dest"><code>--compare-dest</code></a> and <a href="#opt--copy-dest"><code>--copy-dest</code></a>.</p>
+<p>Note that rsync versions prior to 2.6.1 had a bug that could prevent
+<code>--link-dest</code> from working properly for a non-super-user when
+<a href="#opt--owner"><code>--owner</code></a> (<code>-o</code>) was specified (or implied). You can work-around
+this bug by avoiding the <code>-o</code> option (or using <code>--no-o</code>) when sending to an
+old rsync.</p>
+</dd>
+
+<span id="opt-z"></span><dt id="opt--compress"><code>--compress</code>, <code>-z</code><a href="#opt--compress" class="tgt"></a></dt><dd>
+<p>With this option, rsync compresses the file data as it is sent to the
+destination machine, which reduces the amount of data being transmitted&nbsp;-&#8288;-&#8288;
+something that is useful over a slow connection.</p>
+<p>Rsync supports multiple compression methods and will choose one for you
+unless you force the choice using the <a href="#opt--compress-choice"><code>--compress-choice</code></a> (<code>--zc</code>)
+option.</p>
+<p>Run <code>rsync --version</code> to see the default compress list compiled into your
+version.</p>
+<p>When both sides of the transfer are at least 3.2.0, rsync chooses the first
+algorithm in the client's list of choices that is also in the server's list
+of choices. If no common compress choice is found, rsync exits with
+an error. If the remote rsync is too old to support checksum negotiation,
+its list is assumed to be &quot;zlib&quot;.</p>
+<p>The default order can be customized by setting the environment variable
+<a href="#RSYNC_COMPRESS_LIST"><code>RSYNC_COMPRESS_LIST</code></a> to a space-separated list of acceptable
+compression names. If the string contains a &quot;<code>&amp;</code>&quot; character, it is
+separated into the &quot;client string &amp; server string&quot;, otherwise the same
+string applies to both. If the string (or string portion) contains no
+non-whitespace characters, the default compress list is used. Any unknown
+compression names are discarded from the list, but a list with only invalid
+names results in a failed negotiation.</p>
+<p>There are some older rsync versions that were configured to reject a <code>-z</code>
+option and require the use of <code>-zz</code> because their compression library was
+not compatible with the default zlib compression method. You can usually
+ignore this weirdness unless the rsync server complains and tells you to
+specify <code>-zz</code>.</p>
+</dd>
+
+<span id="opt--zc"></span><dt id="opt--compress-choice"><code>--compress-choice=STR</code>, <code>--zc=STR</code><a href="#opt--compress-choice" class="tgt"></a></dt><dd>
+<p>This option can be used to override the automatic negotiation of the
+compression algorithm that occurs when <a href="#opt--compress"><code>--compress</code></a> is used. The
+option implies <a href="#opt--compress"><code>--compress</code></a> unless &quot;none&quot; was specified, which
+instead implies <code>--no-compress</code>.</p>
+<p>The compression options that you may be able to use are:</p>
+<ul>
+<li><code>zstd</code></li>
+<li><code>lz4</code></li>
+<li><code>zlibx</code></li>
+<li><code>zlib</code></li>
+<li><code>none</code></li>
+</ul>
+<p>Run <code>rsync --version</code> to see the default compress list compiled into your
+version (which may differ from the list above).</p>
+<p>Note that if you see an error about an option named <code>--old-compress</code> or
+<code>--new-compress</code>, this is rsync trying to send the <code>--compress-choice=zlib</code>
+or <code>--compress-choice=zlibx</code> option in a backward-compatible manner that
+more rsync versions understand. This error indicates that the older rsync
+version on the server will not allow you to force the compression type.</p>
+<p>Note that the &quot;zlibx&quot; compression algorithm is just the &quot;zlib&quot; algorithm
+with matched data excluded from the compression stream (to try to make it
+more compatible with an external zlib implementation).</p>
+</dd>
+
+<span id="opt--zl"></span><dt id="opt--compress-level"><code>--compress-level=NUM</code>, <code>--zl=NUM</code><a href="#opt--compress-level" class="tgt"></a></dt><dd>
+<p>Explicitly set the compression level to use (see <a href="#opt--compress"><code>--compress</code></a>,
+<code>-z</code>) instead of letting it default. The <a href="#opt--compress"><code>--compress</code></a> option is
+implied as long as the level chosen is not a &quot;don't compress&quot; level for the
+compression algorithm that is in effect (e.g. zlib compression treats level
+0 as &quot;off&quot;).</p>
+<p>The level values vary depending on the checksum in effect. Because rsync
+will negotiate a checksum choice by default (when the remote rsync is new
+enough), it can be good to combine this option with a
+<a href="#opt--compress-choice"><code>--compress-choice</code></a> (<code>--zc</code>) option unless you're sure of the
+choice in effect. For example:</p>
+<blockquote>
+<pre><code>rsync -aiv --zc=zstd --zl=22 host:src/ dest/
+</code></pre>
+</blockquote>
+<p>For zlib &amp; zlibx compression the valid values are from 1 to 9 with 6 being
+the default. Specifying <code>--zl=0</code> turns compression off, and specifying
+<code>--zl=-1</code> chooses the default level of 6.</p>
+<p>For zstd compression the valid values are from -&#8288;131072 to 22 with 3 being
+the default. Specifying 0 chooses the default of 3.</p>
+<p>For lz4 compression there are no levels, so the value is always 0.</p>
+<p>If you specify a too-large or too-small value, the number is silently
+limited to a valid value. This allows you to specify something like
+<code>--zl=999999999</code> and be assured that you'll end up with the maximum
+compression level no matter what algorithm was chosen.</p>
+<p>If you want to know the compression level that is in effect, specify
+<a href="#opt--debug"><code>--debug=nstr</code></a> to see the &quot;negotiated string&quot; results. This will
+report something like &quot;<code>Client compress: zstd (level 3)</code>&quot; (along with the
+checksum choice in effect).</p>
+</dd>
+
+<dt id="opt--skip-compress"><code>--skip-compress=LIST</code><a href="#opt--skip-compress" class="tgt"></a></dt><dd>
+<p><strong>NOTE:</strong> no compression method currently supports per-file compression
+changes, so this option has no effect.</p>
+<p>Override the list of file suffixes that will be compressed as little as
+possible. Rsync sets the compression level on a per-file basis based on
+the file's suffix. If the compression algorithm has an &quot;off&quot; level, then
+no compression occurs for those files. Other algorithms that support
+changing the streaming level on-the-fly will have the level minimized to
+reduces the CPU usage as much as possible for a matching file.</p>
+<p>The <strong>LIST</strong> should be one or more file suffixes (without the dot) separated
+by slashes (<code>/</code>). You may specify an empty string to indicate that no files
+should be skipped.</p>
+<p>Simple character-class matching is supported: each must consist of a list
+of letters inside the square brackets (e.g. no special classes, such as
+&quot;[:alpha:]&quot;, are supported, and '-&#8288;' has no special meaning).</p>
+<p>The characters asterisk (<code>*</code>) and question-mark (<code>?</code>) have no special meaning.</p>
+<p>Here's an example that specifies 6 suffixes to skip (since 1 of the 5 rules
+matches 2 suffixes):</p>
+<blockquote>
+<pre><code>--skip-compress=gz/jpg/mp[34]/7z/bz2
+</code></pre>
+</blockquote>
+<p>The default file suffixes in the skip-compress list in this version of
+rsync are:</p>
+<blockquote>
+<p>3g2
+3gp
+7z
+aac
+ace
+apk
+avi
+bz2
+deb
+dmg
+ear
+f4v
+flac
+flv
+gpg
+gz
+iso
+jar
+jpeg
+jpg
+lrz
+lz
+lz4
+lzma
+lzo
+m1a
+m1v
+m2a
+m2ts
+m2v
+m4a
+m4b
+m4p
+m4r
+m4v
+mka
+mkv
+mov
+mp1
+mp2
+mp3
+mp4
+mpa
+mpeg
+mpg
+mpv
+mts
+odb
+odf
+odg
+odi
+odm
+odp
+ods
+odt
+oga
+ogg
+ogm
+ogv
+ogx
+opus
+otg
+oth
+otp
+ots
+ott
+oxt
+png
+qt
+rar
+rpm
+rz
+rzip
+spx
+squashfs
+sxc
+sxd
+sxg
+sxm
+sxw
+sz
+tbz
+tbz2
+tgz
+tlz
+ts
+txz
+tzo
+vob
+war
+webm
+webp
+xz
+z
+zip
+zst</p>
+</blockquote>
+<p>This list will be replaced by your <code>--skip-compress</code> list in all but one
+situation: a copy from a daemon rsync will add your skipped suffixes to its
+list of non-compressing files (and its list may be configured to a
+different default).</p>
+</dd>
+
+<dt id="opt--numeric-ids"><code>--numeric-ids</code><a href="#opt--numeric-ids" class="tgt"></a></dt><dd>
+<p>With this option rsync will transfer numeric group and user IDs rather than
+using user and group names and mapping them at both ends.</p>
+<p>By default rsync will use the username and groupname to determine what
+ownership to give files. The special uid 0 and the special group 0 are
+never mapped via user/group names even if the <code>--numeric-ids</code> option is not
+specified.</p>
+<p>If a user or group has no name on the source system or it has no match on
+the destination system, then the numeric ID from the source system is used
+instead. See also the <a href="rsyncd.conf.5#use_chroot"><code>use chroot</code></a> setting
+in the rsyncd.conf manpage for some comments on how the chroot setting
+affects rsync's ability to look up the names of the users and groups and
+what you can do about it.</p>
+</dd>
+
+<span id="opt--groupmap"></span><dt id="opt--usermap"><code>--usermap=STRING</code>, <code>--groupmap=STRING</code><a href="#opt--usermap" class="tgt"></a></dt><dd>
+<p>These options allow you to specify users and groups that should be mapped
+to other values by the receiving side. The <strong>STRING</strong> is one or more
+<strong>FROM</strong>:<strong>TO</strong> pairs of values separated by commas. Any matching <strong>FROM</strong>
+value from the sender is replaced with a <strong>TO</strong> value from the receiver.
+You may specify usernames or user IDs for the <strong>FROM</strong> and <strong>TO</strong> values,
+and the <strong>FROM</strong> value may also be a wild-card string, which will be
+matched against the sender's names (wild-cards do NOT match against ID
+numbers, though see below for why a '<code>*</code>' matches everything). You may
+instead specify a range of ID numbers via an inclusive range: LOW-HIGH.
+For example:</p>
+<blockquote>
+<pre><code>--usermap=0-99:nobody,wayne:admin,*:normal --groupmap=usr:1,1:usr
+</code></pre>
+</blockquote>
+<p>The first match in the list is the one that is used. You should specify
+all your user mappings using a single <code>--usermap</code> option, and/or all your
+group mappings using a single <code>--groupmap</code> option.</p>
+<p>Note that the sender's name for the 0 user and group are not transmitted to
+the receiver, so you should either match these values using a 0, or use the
+names in effect on the receiving side (typically &quot;root&quot;). All other
+<strong>FROM</strong> names match those in use on the sending side. All <strong>TO</strong> names
+match those in use on the receiving side.</p>
+<p>Any IDs that do not have a name on the sending side are treated as having
+an empty name for the purpose of matching. This allows them to be matched
+via a &quot;<code>*</code>&quot; or using an empty name. For instance:</p>
+<blockquote>
+<pre><code>--usermap=:nobody --groupmap=*:nobody
+</code></pre>
+</blockquote>
+<p>When the <a href="#opt--numeric-ids"><code>--numeric-ids</code></a> option is used, the sender does not send any
+names, so all the IDs are treated as having an empty name. This means that
+you will need to specify numeric <strong>FROM</strong> values if you want to map these
+nameless IDs to different values.</p>
+<p>For the <code>--usermap</code> option to work, the receiver will need to be running as
+a super-user (see also the <a href="#opt--super"><code>--super</code></a> and <a href="#opt--fake-super"><code>--fake-super</code></a>
+options). For the <code>--groupmap</code> option to work, the receiver will need to
+have permissions to set that group.</p>
+<p>Starting with rsync 3.2.4, the <code>--usermap</code> option implies the
+<a href="#opt--owner"><code>--owner</code></a> (<code>-o</code>) option while the <code>--groupmap</code> option implies the
+<a href="#opt--group"><code>--group</code></a> (<code>-g</code>) option (since rsync needs to have those options
+enabled for the mapping options to work).</p>
+<p>An older rsync client may need to use <a href="#opt-s"><code>-s</code></a> to avoid a complaint
+about wildcard characters, but a modern rsync handles this automatically.</p>
+</dd>
+
+<dt id="opt--chown"><code>--chown=USER:GROUP</code><a href="#opt--chown" class="tgt"></a></dt><dd>
+<p>This option forces all files to be owned by USER with group GROUP. This is
+a simpler interface than using <a href="#opt--usermap"><code>--usermap</code></a> &amp; <a href="#opt--groupmap"><code>--groupmap</code></a>
+directly, but it is implemented using those options internally so they
+cannot be mixed. If either the USER or GROUP is empty, no mapping for the
+omitted user/group will occur. If GROUP is empty, the trailing colon may
+be omitted, but if USER is empty, a leading colon must be supplied.</p>
+<p>If you specify &quot;<code>--chown=foo:bar</code>&quot;, this is exactly the same as specifying
+&quot;<code>--usermap=*:foo --groupmap=*:bar</code>&quot;, only easier (and with the same
+implied <a href="#opt--owner"><code>--owner</code></a> and/or <a href="#opt--group"><code>--group</code></a> options).</p>
+<p>An older rsync client may need to use <a href="#opt-s"><code>-s</code></a> to avoid a complaint
+about wildcard characters, but a modern rsync handles this automatically.</p>
+</dd>
+
+<dt id="opt--timeout"><code>--timeout=SECONDS</code><a href="#opt--timeout" class="tgt"></a></dt><dd>
+<p>This option allows you to set a maximum I/O timeout in seconds. If no data
+is transferred for the specified time then rsync will exit. The default is
+0, which means no timeout.</p>
+</dd>
+
+<dt id="opt--contimeout"><code>--contimeout=SECONDS</code><a href="#opt--contimeout" class="tgt"></a></dt><dd>
+<p>This option allows you to set the amount of time that rsync will wait for
+its connection to an rsync daemon to succeed. If the timeout is reached,
+rsync exits with an error.</p>
+</dd>
+
+<dt id="opt--address"><code>--address=ADDRESS</code><a href="#opt--address" class="tgt"></a></dt><dd>
+<p>By default rsync will bind to the wildcard address when connecting to an
+rsync daemon. The <code>--address</code> option allows you to specify a specific IP
+address (or hostname) to bind to.</p>
+<p>See also <a href="#dopt--address">the daemon version of the <code>--address</code> option</a>.</p>
+</dd>
+
+<dt id="opt--port"><code>--port=PORT</code><a href="#opt--port" class="tgt"></a></dt><dd>
+<p>This specifies an alternate TCP port number to use rather than the default
+of 873. This is only needed if you are using the double-colon (::) syntax
+to connect with an rsync daemon (since the URL syntax has a way to specify
+the port as a part of the URL).</p>
+<p>See also <a href="#dopt--port">the daemon version of the <code>--port</code> option</a>.</p>
+</dd>
+
+<dt id="opt--sockopts"><code>--sockopts=OPTIONS</code><a href="#opt--sockopts" class="tgt"></a></dt><dd>
+<p>This option can provide endless fun for people who like to tune their
+systems to the utmost degree. You can set all sorts of socket options
+which may make transfers faster (or slower!). Read the manpage for the
+<code>setsockopt()</code> system call for details on some of the options you may be
+able to set. By default no special socket options are set. This only
+affects direct socket connections to a remote rsync daemon.</p>
+<p>See also <a href="#dopt--sockopts">the daemon version of the <code>--sockopts</code> option</a>.</p>
+</dd>
+
+<dt id="opt--blocking-io"><code>--blocking-io</code><a href="#opt--blocking-io" class="tgt"></a></dt><dd>
+<p>This tells rsync to use blocking I/O when launching a remote shell
+transport. If the remote shell is either rsh or remsh, rsync defaults to
+using blocking I/O, otherwise it defaults to using non-blocking I/O. (Note
+that ssh prefers non-blocking I/O.)</p>
+</dd>
+
+<dt id="opt--outbuf"><code>--outbuf=MODE</code><a href="#opt--outbuf" class="tgt"></a></dt><dd>
+<p>This sets the output buffering mode. The mode can be None (aka
+Unbuffered), Line, or Block (aka Full). You may specify as little as a
+single letter for the mode, and use upper or lower case.</p>
+<p>The main use of this option is to change Full buffering to Line buffering
+when rsync's output is going to a file or pipe.</p>
+</dd>
+
+<span id="opt-i"></span><dt id="opt--itemize-changes"><code>--itemize-changes</code>, <code>-i</code><a href="#opt--itemize-changes" class="tgt"></a></dt><dd>
+<p>Requests a simple itemized list of the changes that are being made to each
+file, including attribute changes. This is exactly the same as specifying
+<a href="#opt--out-format"><code>--out-format='%i %n%L'</code></a>. If you repeat the option, unchanged
+files will also be output, but only if the receiving rsync is at least
+version 2.6.7 (you can use <code>-vv</code> with older versions of rsync, but that
+also turns on the output of other verbose messages).</p>
+<p>The &quot;%i&quot; escape has a cryptic output that is 11 letters long. The general
+format is like the string <code>YXcstpoguax</code>, where <strong>Y</strong> is replaced by the type
+of update being done, <strong>X</strong> is replaced by the file-type, and the other
+letters represent attributes that may be output if they are being modified.</p>
+<p>The update types that replace the <strong>Y</strong> are as follows:</p>
+<ul>
+<li>A <code>&lt;</code> means that a file is being transferred to the remote host (sent).</li>
+<li>A <code>&gt;</code> means that a file is being transferred to the local host
+(received).</li>
+<li>A <code>c</code> means that a local change/creation is occurring for the item (such
+as the creation of a directory or the changing of a symlink, etc.).</li>
+<li>A <code>h</code> means that the item is a hard link to another item (requires
+<a href="#opt--hard-links"><code>--hard-links</code></a>).</li>
+<li>A <code>.</code> means that the item is not being updated (though it might have
+attributes that are being modified).</li>
+<li>A <code>*</code> means that the rest of the itemized-output area contains a message
+(e.g. &quot;deleting&quot;).</li>
+</ul>
+<p>The file-types that replace the <strong>X</strong> are: <code>f</code> for a file, a <code>d</code> for a
+directory, an <code>L</code> for a symlink, a <code>D</code> for a device, and a <code>S</code> for a
+special file (e.g. named sockets and fifos).</p>
+<p>The other letters in the string indicate if some attributes of the file
+have changed, as follows:</p>
+<ul>
+<li>&quot;<code>.</code>&quot; -&#8288; the attribute is unchanged.</li>
+<li>&quot;<code>+</code>&quot; -&#8288; the file is newly created.</li>
+<li>&quot;<code> </code>&quot; -&#8288; all the attributes are unchanged (all dots turn to spaces).</li>
+<li>&quot;<code>?</code>&quot; -&#8288; the change is unknown (when the remote rsync is old).</li>
+<li>A letter indicates an attribute is being updated.</li>
+</ul>
+<p>The attribute that is associated with each letter is as follows:</p>
+<ul>
+<li>A <code>c</code> means either that a regular file has a different checksum (requires
+<a href="#opt--checksum"><code>--checksum</code></a>) or that a symlink, device, or special file has a
+changed value. Note that if you are sending files to an rsync prior to
+3.0.1, this change flag will be present only for checksum-differing
+regular files.</li>
+<li>A <code>s</code> means the size of a regular file is different and will be updated
+by the file transfer.</li>
+<li>A <code>t</code> means the modification time is different and is being updated to
+the sender's value (requires <a href="#opt--times"><code>--times</code></a>). An alternate value of
+<code>T</code> means that the modification time will be set to the transfer time,
+which happens when a file/symlink/device is updated without
+<a href="#opt--times"><code>--times</code></a> and when a symlink is changed and the receiver can't
+set its time. (Note: when using an rsync 3.0.0 client, you might see the
+<code>s</code> flag combined with <code>t</code> instead of the proper <code>T</code> flag for this
+time-setting failure.)</li>
+<li>A <code>p</code> means the permissions are different and are being updated to the
+sender's value (requires <a href="#opt--perms"><code>--perms</code></a>).</li>
+<li>An <code>o</code> means the owner is different and is being updated to the sender's
+value (requires <a href="#opt--owner"><code>--owner</code></a> and super-user privileges).</li>
+<li>A <code>g</code> means the group is different and is being updated to the sender's
+value (requires <a href="#opt--group"><code>--group</code></a> and the authority to set the group).</li>
+<li>A <code>u</code>|<code>n</code>|<code>b</code> indicates the following information:
+<ul>
+<li><code>u</code> means the access (use) time is different and is being updated to
+the sender's value (requires <a href="#opt--atimes"><code>--atimes</code></a>)</li>
+<li><code>n</code> means the create time (newness) is different and is being updated
+to the sender's value (requires <a href="#opt--crtimes"><code>--crtimes</code></a>)</li>
+<li><code>b</code> means that both the access and create times are being updated</li>
+</ul>
+</li>
+<li>The <code>a</code> means that the ACL information is being changed.</li>
+<li>The <code>x</code> means that the extended attribute information is being changed.</li>
+</ul>
+<p>One other output is possible: when deleting files, the &quot;%i&quot; will output the
+string &quot;<code>*deleting</code>&quot; for each item that is being removed (assuming that you
+are talking to a recent enough rsync that it logs deletions instead of
+outputting them as a verbose message).</p>
+</dd>
+
+<dt id="opt--out-format"><code>--out-format=FORMAT</code><a href="#opt--out-format" class="tgt"></a></dt><dd>
+<p>This allows you to specify exactly what the rsync client outputs to the
+user on a per-update basis. The format is a text string containing
+embedded single-character escape sequences prefixed with a percent (%)
+character. A default format of &quot;%n%L&quot; is assumed if either
+<a href="#opt--info"><code>--info=name</code></a> or <a href="#opt-v"><code>-v</code></a> is specified (this tells you just the
+name of the file and, if the item is a link, where it points). For a full
+list of the possible escape characters, see the <a href="rsyncd.conf.5#log_format"><code>log format</code></a> setting in the rsyncd.conf manpage.</p>
+<p>Specifying the <code>--out-format</code> option implies the <a href="#opt--info"><code>--info=name</code></a>
+option, which will mention each file, dir, etc. that gets updated in a
+significant way (a transferred file, a recreated symlink/device, or a
+touched directory). In addition, if the itemize-changes escape (%i) is
+included in the string (e.g. if the <a href="#opt--itemize-changes"><code>--itemize-changes</code></a> option was
+used), the logging of names increases to mention any item that is changed
+in any way (as long as the receiving side is at least 2.6.4). See the
+<a href="#opt--itemize-changes"><code>--itemize-changes</code></a> option for a description of the output of &quot;%i&quot;.</p>
+<p>Rsync will output the out-format string prior to a file's transfer unless
+one of the transfer-statistic escapes is requested, in which case the
+logging is done at the end of the file's transfer. When this late logging
+is in effect and <a href="#opt--progress"><code>--progress</code></a> is also specified, rsync will also
+output the name of the file being transferred prior to its progress
+information (followed, of course, by the out-format output).</p>
+</dd>
+
+<dt id="opt--log-file"><code>--log-file=FILE</code><a href="#opt--log-file" class="tgt"></a></dt><dd>
+<p>This option causes rsync to log what it is doing to a file. This is
+similar to the logging that a daemon does, but can be requested for the
+client side and/or the server side of a non-daemon transfer. If specified
+as a client option, transfer logging will be enabled with a default format
+of &quot;%i %n%L&quot;. See the <a href="#opt--log-file-format"><code>--log-file-format</code></a> option if you wish to
+override this.</p>
+<p>Here's an example command that requests the remote side to log what is
+happening:</p>
+<blockquote>
+<pre><code>rsync -av --remote-option=--log-file=/tmp/rlog src/ dest/
+</code></pre>
+</blockquote>
+<p>This is very useful if you need to debug why a connection is closing
+unexpectedly.</p>
+<p>See also <a href="#dopt--log-file">the daemon version of the <code>--log-file</code> option</a>.</p>
+</dd>
+
+<dt id="opt--log-file-format"><code>--log-file-format=FORMAT</code><a href="#opt--log-file-format" class="tgt"></a></dt><dd>
+<p>This allows you to specify exactly what per-update logging is put into the
+file specified by the <a href="#opt--log-file"><code>--log-file</code></a> option (which must also be
+specified for this option to have any effect). If you specify an empty
+string, updated files will not be mentioned in the log file. For a list of
+the possible escape characters, see the <a href="rsyncd.conf.5#log_format"><code>log format</code></a>
+setting in the rsyncd.conf manpage.</p>
+<p>The default FORMAT used if <a href="#opt--log-file"><code>--log-file</code></a> is specified and this
+option is not is '%i %n%L'.</p>
+<p>See also <a href="#dopt--log-file-format">the daemon version of the <code>--log-file-format</code>
+option</a>.</p>
+</dd>
+
+<dt id="opt--stats"><code>--stats</code><a href="#opt--stats" class="tgt"></a></dt><dd>
+<p>This tells rsync to print a verbose set of statistics on the file transfer,
+allowing you to tell how effective rsync's delta-transfer algorithm is for
+your data. This option is equivalent to <a href="#opt--info"><code>--info=stats2</code></a> if
+combined with 0 or 1 <a href="#opt-v"><code>-v</code></a> options, or <a href="#opt--info"><code>--info=stats3</code></a> if
+combined with 2 or more <a href="#opt-v"><code>-v</code></a> options.</p>
+<p>The current statistics are as follows:</p>
+<ul>
+<li><code>Number of files</code> is the count of all &quot;files&quot; (in the generic sense),
+which includes directories, symlinks, etc. The total count will be
+followed by a list of counts by filetype (if the total is non-zero). For
+example: &quot;(reg: 5, dir: 3, link: 2, dev: 1, special: 1)&quot; lists the totals
+for regular files, directories, symlinks, devices, and special files. If
+any of value is 0, it is completely omitted from the list.</li>
+<li><code>Number of created files</code> is the count of how many &quot;files&quot; (generic
+sense) were created (as opposed to updated). The total count will be
+followed by a list of counts by filetype (if the total is non-zero).</li>
+<li><code>Number of deleted files</code> is the count of how many &quot;files&quot; (generic
+sense) were deleted. The total count will be
+followed by a list of counts by filetype (if the total is non-zero).
+Note that this line is only output if deletions are in effect, and only
+if protocol 31 is being used (the default for rsync 3.1.x).</li>
+<li><code>Number of regular files transferred</code> is the count of normal files that
+were updated via rsync's delta-transfer algorithm, which does not include
+dirs, symlinks, etc. Note that rsync 3.1.0 added the word &quot;regular&quot; into
+this heading.</li>
+<li><code>Total file size</code> is the total sum of all file sizes in the transfer.
+This does not count any size for directories or special files, but does
+include the size of symlinks.</li>
+<li><code>Total transferred file size</code> is the total sum of all files sizes for
+just the transferred files.</li>
+<li><code>Literal data</code> is how much unmatched file-update data we had to send to
+the receiver for it to recreate the updated files.</li>
+<li><code>Matched data</code> is how much data the receiver got locally when recreating
+the updated files.</li>
+<li><code>File list size</code> is how big the file-list data was when the sender sent
+it to the receiver. This is smaller than the in-memory size for the file
+list due to some compressing of duplicated data when rsync sends the
+list.</li>
+<li><code>File list generation time</code> is the number of seconds that the sender
+spent creating the file list. This requires a modern rsync on the
+sending side for this to be present.</li>
+<li><code>File list transfer time</code> is the number of seconds that the sender spent
+sending the file list to the receiver.</li>
+<li><code>Total bytes sent</code> is the count of all the bytes that rsync sent from the
+client side to the server side.</li>
+<li><code>Total bytes received</code> is the count of all non-message bytes that rsync
+received by the client side from the server side. &quot;Non-message&quot; bytes
+means that we don't count the bytes for a verbose message that the server
+sent to us, which makes the stats more consistent.</li>
+</ul>
+</dd>
+
+<span id="opt-8"></span><dt id="opt--8-bit-output"><code>--8-bit-output</code>, <code>-8</code><a href="#opt--8-bit-output" class="tgt"></a></dt><dd>
+<p>This tells rsync to leave all high-bit characters unescaped in the output
+instead of trying to test them to see if they're valid in the current
+locale and escaping the invalid ones. All control characters (but never
+tabs) are always escaped, regardless of this option's setting.</p>
+<p>The escape idiom that started in 2.6.7 is to output a literal backslash
+(<code>\</code>) and a hash (<code>#</code>), followed by exactly 3 octal digits. For example, a
+newline would output as &quot;<code>\#012</code>&quot;. A literal backslash that is in a
+filename is not escaped unless it is followed by a hash and 3 digits (0-9).</p>
+</dd>
+
+<span id="opt-h"></span><dt id="opt--human-readable"><code>--human-readable</code>, <code>-h</code><a href="#opt--human-readable" class="tgt"></a></dt><dd>
+<p>Output numbers in a more human-readable format. There are 3 possible levels:</p>
+<ol>
+<li>output numbers with a separator between each set of 3 digits (either a
+comma or a period, depending on if the decimal point is represented by a
+period or a comma).</li>
+<li>output numbers in units of 1000 (with a character suffix for larger
+units&nbsp;-&#8288;-&#8288; see below).</li>
+<li>output numbers in units of 1024.</li>
+</ol>
+<p>The default is human-readable level 1. Each <code>-h</code> option increases the
+level by one. You can take the level down to 0 (to output numbers as pure
+digits) by specifying the <code>--no-human-readable</code> (<code>--no-h</code>) option.</p>
+<p>The unit letters that are appended in levels 2 and 3 are: <code>K</code> (kilo), <code>M</code>
+(mega), <code>G</code> (giga), <code>T</code> (tera), or <code>P</code> (peta). For example, a 1234567-byte
+file would output as 1.23M in level-2 (assuming that a period is your local
+decimal point).</p>
+<p>Backward compatibility note: versions of rsync prior to 3.1.0 do not
+support human-readable level 1, and they default to level 0. Thus,
+specifying one or two <code>-h</code> options will behave in a comparable manner in
+old and new versions as long as you didn't specify a <code>--no-h</code> option prior
+to one or more <code>-h</code> options. See the <a href="#opt--list-only"><code>--list-only</code></a> option for one
+difference.</p>
+</dd>
+
+<dt id="opt--partial"><code>--partial</code><a href="#opt--partial" class="tgt"></a></dt><dd>
+<p>By default, rsync will delete any partially transferred file if the
+transfer is interrupted. In some circumstances it is more desirable to
+keep partially transferred files. Using the <code>--partial</code> option tells rsync
+to keep the partial file which should make a subsequent transfer of the
+rest of the file much faster.</p>
+</dd>
+
+<dt id="opt--partial-dir"><code>--partial-dir=DIR</code><a href="#opt--partial-dir" class="tgt"></a></dt><dd>
+<p>This option modifies the behavior of the <a href="#opt--partial"><code>--partial</code></a> option while
+also implying that it be enabled. This enhanced partial-file method puts
+any partially transferred files into the specified <u>DIR</u> instead of writing
+the partial file out to the destination file. On the next transfer, rsync
+will use a file found in this dir as data to speed up the resumption of the
+transfer and then delete it after it has served its purpose.</p>
+<p>Note that if <a href="#opt--whole-file"><code>--whole-file</code></a> is specified (or implied), any
+partial-dir files that are found for a file that is being updated will
+simply be removed (since rsync is sending files without using rsync's
+delta-transfer algorithm).</p>
+<p>Rsync will create the <u>DIR</u> if it is missing, but just the last dir&nbsp;-&#8288;-&#8288; not
+the whole path. This makes it easy to use a relative path (such as
+&quot;<code>--partial-dir=.rsync-partial</code>&quot;) to have rsync create the
+partial-directory in the destination file's directory when it is needed,
+and then remove it again when the partial file is deleted. Note that this
+directory removal is only done for a relative pathname, as it is expected
+that an absolute path is to a directory that is reserved for partial-dir
+work.</p>
+<p>If the partial-dir value is not an absolute path, rsync will add an exclude
+rule at the end of all your existing excludes. This will prevent the
+sending of any partial-dir files that may exist on the sending side, and
+will also prevent the untimely deletion of partial-dir items on the
+receiving side. An example: the above <code>--partial-dir</code> option would add the
+equivalent of this &quot;perishable&quot; exclude at the end of any other filter
+rules: <code>-f '-p .rsync-partial/'</code></p>
+<p>If you are supplying your own exclude rules, you may need to add your own
+exclude/hide/protect rule for the partial-dir because:</p>
+<ol>
+<li>the auto-added rule may be ineffective at the end of your other rules, or</li>
+<li>you may wish to override rsync's exclude choice.</li>
+</ol>
+<p>For instance, if you want to make rsync clean-up any left-over partial-dirs
+that may be lying around, you should specify <a href="#opt--delete-after"><code>--delete-after</code></a> and
+add a &quot;risk&quot; filter rule, e.g. <code>-f 'R .rsync-partial/'</code>. Avoid using
+<a href="#opt--delete-before"><code>--delete-before</code></a> or <a href="#opt--delete-during"><code>--delete-during</code></a> unless you don't
+need rsync to use any of the left-over partial-dir data during the current
+run.</p>
+<p>IMPORTANT: the <code>--partial-dir</code> should not be writable by other users or it
+is a security risk! E.g. AVOID &quot;/tmp&quot;!</p>
+<p>You can also set the partial-dir value the <a href="#RSYNC_PARTIAL_DIR"><code>RSYNC_PARTIAL_DIR</code></a>
+environment variable. Setting this in the environment does not force
+<a href="#opt--partial"><code>--partial</code></a> to be enabled, but rather it affects where partial
+files go when <a href="#opt--partial"><code>--partial</code></a> is specified. For instance, instead of
+using <code>--partial-dir=.rsync-tmp</code> along with <a href="#opt--progress"><code>--progress</code></a>, you could
+set <a href="#RSYNC_PARTIAL_DIR"><code>RSYNC_PARTIAL_DIR=.rsync-tmp</code></a> in your environment and then use
+the <a href="#opt-P"><code>-P</code></a> option to turn on the use of the .rsync-tmp dir for
+partial transfers. The only times that the <a href="#opt--partial"><code>--partial</code></a> option does
+not look for this environment value are:</p>
+<ol>
+<li>when <a href="#opt--inplace"><code>--inplace</code></a> was specified (since <a href="#opt--inplace"><code>--inplace</code></a>
+conflicts with <code>--partial-dir</code>), and</li>
+<li>when <a href="#opt--delay-updates"><code>--delay-updates</code></a> was specified (see below).</li>
+</ol>
+<p>When a modern rsync resumes the transfer of a file in the partial-dir, that
+partial file is now updated in-place instead of creating yet another
+tmp-file copy (so it maxes out at dest + tmp instead of dest + partial +
+tmp). This requires both ends of the transfer to be at least version
+3.2.0.</p>
+<p>For the purposes of the daemon-config's &quot;<code>refuse options</code>&quot; setting,
+<code>--partial-dir</code> does <u>not</u> imply <a href="#opt--partial"><code>--partial</code></a>. This is so that a
+refusal of the <a href="#opt--partial"><code>--partial</code></a> option can be used to disallow the
+overwriting of destination files with a partial transfer, while still
+allowing the safer idiom provided by <code>--partial-dir</code>.</p>
+</dd>
+
+<dt id="opt--delay-updates"><code>--delay-updates</code><a href="#opt--delay-updates" class="tgt"></a></dt><dd>
+<p>This option puts the temporary file from each updated file into a holding
+directory until the end of the transfer, at which time all the files are
+renamed into place in rapid succession. This attempts to make the updating
+of the files a little more atomic. By default the files are placed into a
+directory named <code>.~tmp~</code> in each file's destination directory, but if
+you've specified the <a href="#opt--partial-dir"><code>--partial-dir</code></a> option, that directory will be
+used instead. See the comments in the <a href="#opt--partial-dir"><code>--partial-dir</code></a> section for
+a discussion of how this <code>.~tmp~</code> dir will be excluded from the transfer,
+and what you can do if you want rsync to cleanup old <code>.~tmp~</code> dirs that
+might be lying around. Conflicts with <a href="#opt--inplace"><code>--inplace</code></a> and
+<a href="#opt--append"><code>--append</code></a>.</p>
+<p>This option implies <a href="#opt--no-inc-recursive"><code>--no-inc-recursive</code></a> since it needs the full
+file list in memory in order to be able to iterate over it at the end.</p>
+<p>This option uses more memory on the receiving side (one bit per file
+transferred) and also requires enough free disk space on the receiving side
+to hold an additional copy of all the updated files. Note also that you
+should not use an absolute path to <a href="#opt--partial-dir"><code>--partial-dir</code></a> unless:</p>
+<ol>
+<li>there is no chance of any of the files in the transfer having the same
+name (since all the updated files will be put into a single directory if
+the path is absolute), and</li>
+<li>there are no mount points in the hierarchy (since the delayed updates
+will fail if they can't be renamed into place).</li>
+</ol>
+<p>See also the &quot;atomic-rsync&quot; python script in the &quot;support&quot; subdir for an
+update algorithm that is even more atomic (it uses <a href="#opt--link-dest"><code>--link-dest</code></a>
+and a parallel hierarchy of files).</p>
+</dd>
+
+<span id="opt-m"></span><dt id="opt--prune-empty-dirs"><code>--prune-empty-dirs</code>, <code>-m</code><a href="#opt--prune-empty-dirs" class="tgt"></a></dt><dd>
+<p>This option tells the receiving rsync to get rid of empty directories from
+the file-list, including nested directories that have no non-directory
+children. This is useful for avoiding the creation of a bunch of useless
+directories when the sending rsync is recursively scanning a hierarchy of
+files using include/exclude/filter rules.</p>
+<p>This option can still leave empty directories on the receiving side if you
+make use of <a href="#TRANSFER_RULES">TRANSFER_RULES</a>.</p>
+<p>Because the file-list is actually being pruned, this option also affects
+what directories get deleted when a delete is active. However, keep in
+mind that excluded files and directories can prevent existing items from
+being deleted due to an exclude both hiding source files and protecting
+destination files. See the perishable filter-rule option for how to avoid
+this.</p>
+<p>You can prevent the pruning of certain empty directories from the file-list
+by using a global &quot;protect&quot; filter. For instance, this option would ensure
+that the directory &quot;emptydir&quot; was kept in the file-list:</p>
+<blockquote>
+<pre><code>--filter 'protect emptydir/'
+</code></pre>
+</blockquote>
+<p>Here's an example that copies all .pdf files in a hierarchy, only creating
+the necessary destination directories to hold the .pdf files, and ensures
+that any superfluous files and directories in the destination are removed
+(note the hide filter of non-directories being used instead of an exclude):</p>
+<blockquote>
+<pre><code>rsync -avm --del --include='*.pdf' -f 'hide,! */' src/ dest
+</code></pre>
+</blockquote>
+<p>If you didn't want to remove superfluous destination files, the more
+time-honored options of <code>--include='*/' --exclude='*'</code> would work
+fine in place of the hide-filter (if that is more natural to you).</p>
+</dd>
+
+<dt id="opt--progress"><code>--progress</code><a href="#opt--progress" class="tgt"></a></dt><dd>
+<p>This option tells rsync to print information showing the progress of the
+transfer. This gives a bored user something to watch. With a modern rsync
+this is the same as specifying <a href="#opt--info"><code>--info=flist2,name,progress</code></a>, but
+any user-supplied settings for those info flags takes precedence (e.g.
+<a href="#opt--info"><code>--info=flist0 --progress</code></a>).</p>
+<p>While rsync is transferring a regular file, it updates a progress line that
+looks like this:</p>
+<blockquote>
+<pre><code>782448 63% 110.64kB/s 0:00:04
+</code></pre>
+</blockquote>
+<p>In this example, the receiver has reconstructed 782448 bytes or 63% of the
+sender's file, which is being reconstructed at a rate of 110.64 kilobytes
+per second, and the transfer will finish in 4 seconds if the current rate
+is maintained until the end.</p>
+<p>These statistics can be misleading if rsync's delta-transfer algorithm is
+in use. For example, if the sender's file consists of the basis file
+followed by additional data, the reported rate will probably drop
+dramatically when the receiver gets to the literal data, and the transfer
+will probably take much longer to finish than the receiver estimated as it
+was finishing the matched part of the file.</p>
+<p>When the file transfer finishes, rsync replaces the progress line with a
+summary line that looks like this:</p>
+<blockquote>
+<pre><code>1,238,099 100% 146.38kB/s 0:00:08 (xfr#5, to-chk=169/396)
+</code></pre>
+</blockquote>
+<p>In this example, the file was 1,238,099 bytes long in total, the average
+rate of transfer for the whole file was 146.38 kilobytes per second over
+the 8 seconds that it took to complete, it was the 5th transfer of a
+regular file during the current rsync session, and there are 169 more files
+for the receiver to check (to see if they are up-to-date or not) remaining
+out of the 396 total files in the file-list.</p>
+<p>In an incremental recursion scan, rsync won't know the total number of
+files in the file-list until it reaches the ends of the scan, but since it
+starts to transfer files during the scan, it will display a line with the
+text &quot;ir-chk&quot; (for incremental recursion check) instead of &quot;to-chk&quot; until
+the point that it knows the full size of the list, at which point it will
+switch to using &quot;to-chk&quot;. Thus, seeing &quot;ir-chk&quot; lets you know that the
+total count of files in the file list is still going to increase (and each
+time it does, the count of files left to check will increase by the number
+of the files added to the list).</p>
+</dd>
+
+<dt id="opt-P"><code>-P</code><a href="#opt-P" class="tgt"></a></dt><dd>
+<p>The <code>-P</code> option is equivalent to &quot;<a href="#opt--partial"><code>--partial</code></a>
+<a href="#opt--progress"><code>--progress</code></a>&quot;. Its purpose is to make it much easier to specify
+these two options for a long transfer that may be interrupted.</p>
+<p>There is also a <a href="#opt--info"><code>--info=progress2</code></a> option that outputs statistics
+based on the whole transfer, rather than individual files. Use this flag
+without outputting a filename (e.g. avoid <code>-v</code> or specify
+<a href="#opt--info"><code>--info=name0</code></a>) if you want to see how the transfer is doing
+without scrolling the screen with a lot of names. (You don't need to
+specify the <a href="#opt--progress"><code>--progress</code></a> option in order to use
+<a href="#opt--info"><code>--info=progress2</code></a>.)</p>
+<p>Finally, you can get an instant progress report by sending rsync a signal
+of either SIGINFO or SIGVTALRM. On BSD systems, a SIGINFO is generated by
+typing a Ctrl+T (Linux doesn't currently support a SIGINFO signal). When
+the client-side process receives one of those signals, it sets a flag to
+output a single progress report which is output when the current file
+transfer finishes (so it may take a little time if a big file is being
+handled when the signal arrives). A filename is output (if needed)
+followed by the <a href="#opt--info"><code>--info=progress2</code></a> format of progress info. If you
+don't know which of the 3 rsync processes is the client process, it's OK to
+signal all of them (since the non-client processes ignore the signal).</p>
+<p>CAUTION: sending SIGVTALRM to an older rsync (pre-3.2.0) will kill it.</p>
+</dd>
+
+<dt id="opt--password-file"><code>--password-file=FILE</code><a href="#opt--password-file" class="tgt"></a></dt><dd>
+<p>This option allows you to provide a password for accessing an rsync daemon
+via a file or via standard input if <strong>FILE</strong> is <code>-</code>. The file should
+contain just the password on the first line (all other lines are ignored).
+Rsync will exit with an error if <strong>FILE</strong> is world readable or if a
+root-run rsync command finds a non-root-owned file.</p>
+<p>This option does not supply a password to a remote shell transport such as
+ssh; to learn how to do that, consult the remote shell's documentation.
+When accessing an rsync daemon using a remote shell as the transport, this
+option only comes into effect after the remote shell finishes its
+authentication (i.e. if you have also specified a password in the daemon's
+config file).</p>
+</dd>
+
+<dt id="opt--early-input"><code>--early-input=FILE</code><a href="#opt--early-input" class="tgt"></a></dt><dd>
+<p>This option allows rsync to send up to 5K of data to the &quot;early exec&quot;
+script on its stdin. One possible use of this data is to give the script a
+secret that can be used to mount an encrypted filesystem (which you should
+unmount in the the &quot;post-xfer exec&quot; script).</p>
+<p>The daemon must be at least version 3.2.1.</p>
+</dd>
+
+<dt id="opt--list-only"><code>--list-only</code><a href="#opt--list-only" class="tgt"></a></dt><dd>
+<p>This option will cause the source files to be listed instead of
+transferred. This option is inferred if there is a single source arg and
+no destination specified, so its main uses are:</p>
+<ol>
+<li>to turn a copy command that includes a destination arg into a
+file-listing command, or</li>
+<li>to be able to specify more than one source arg. Note: be sure to
+include the destination.</li>
+</ol>
+<p>CAUTION: keep in mind that a source arg with a wild-card is expanded by the
+shell into multiple args, so it is never safe to try to specify a single
+wild-card arg to try to infer this option. A safe example is:</p>
+<blockquote>
+<pre><code>rsync -av --list-only foo* dest/
+</code></pre>
+</blockquote>
+<p>This option always uses an output format that looks similar to this:</p>
+<blockquote>
+<pre><code>drwxrwxr-x 4,096 2022/09/30 12:53:11 support
+-rw-rw-r-- 80 2005/01/11 10:37:37 support/Makefile
+</code></pre>
+</blockquote>
+<p>The only option that affects this output style is (as of 3.1.0) the
+<a href="#opt--human-readable"><code>--human-readable</code></a> (<code>-h</code>) option. The default is to output sizes
+as byte counts with digit separators (in a 14-character-width column).
+Specifying at least one <code>-h</code> option makes the sizes output with unit
+suffixes. If you want old-style bytecount sizes without digit separators
+(and an 11-character-width column) use <code>--no-h</code>.</p>
+<p>Compatibility note: when requesting a remote listing of files from an rsync
+that is version 2.6.3 or older, you may encounter an error if you ask for a
+non-recursive listing. This is because a file listing implies the
+<a href="#opt--dirs"><code>--dirs</code></a> option w/o <a href="#opt--recursive"><code>--recursive</code></a>, and older rsyncs don't
+have that option. To avoid this problem, either specify the <code>--no-dirs</code>
+option (if you don't need to expand a directory's content), or turn on
+recursion and exclude the content of subdirectories: <code>-r --exclude='/*/*'</code>.</p>
+</dd>
+
+<dt id="opt--bwlimit"><code>--bwlimit=RATE</code><a href="#opt--bwlimit" class="tgt"></a></dt><dd>
+<p>This option allows you to specify the maximum transfer rate for the data
+sent over the socket, specified in units per second. The RATE value can be
+suffixed with a string to indicate a size multiplier, and may be a
+fractional value (e.g. <code>--bwlimit=1.5m</code>). If no suffix is specified, the
+value will be assumed to be in units of 1024 bytes (as if &quot;K&quot; or &quot;KiB&quot; had
+been appended). See the <a href="#opt--max-size"><code>--max-size</code></a> option for a description of
+all the available suffixes. A value of 0 specifies no limit.</p>
+<p>For backward-compatibility reasons, the rate limit will be rounded to the
+nearest KiB unit, so no rate smaller than 1024 bytes per second is
+possible.</p>
+<p>Rsync writes data over the socket in blocks, and this option both limits
+the size of the blocks that rsync writes, and tries to keep the average
+transfer rate at the requested limit. Some burstiness may be seen where
+rsync writes out a block of data and then sleeps to bring the average rate
+into compliance.</p>
+<p>Due to the internal buffering of data, the <a href="#opt--progress"><code>--progress</code></a> option may
+not be an accurate reflection on how fast the data is being sent. This is
+because some files can show up as being rapidly sent when the data is
+quickly buffered, while other can show up as very slow when the flushing of
+the output buffer occurs. This may be fixed in a future version.</p>
+<p>See also <a href="#dopt--bwlimit">the daemon version of the <code>--bwlimit</code> option</a>.</p>
+</dd>
+
+<span id="opt--time-limit"></span><dt id="opt--stop-after"><code>--stop-after=MINS</code>, (<code>--time-limit=MINS</code>)<a href="#opt--stop-after" class="tgt"></a></dt><dd>
+<p>This option tells rsync to stop copying when the specified number of
+minutes has elapsed.</p>
+<p>For maximal flexibility, rsync does not communicate this option to the
+remote rsync since it is usually enough that one side of the connection
+quits as specified. This allows the option's use even when only one side
+of the connection supports it. You can tell the remote side about the time
+limit using <a href="#opt--remote-option"><code>--remote-option</code></a> (<code>-M</code>), should the need arise.</p>
+<p>The <code>--time-limit</code> version of this option is deprecated.</p>
+</dd>
+
+<dt id="opt--stop-at"><code>--stop-at=y-m-dTh:m</code><a href="#opt--stop-at" class="tgt"></a></dt><dd>
+<p>This option tells rsync to stop copying when the specified point in time
+has been reached. The date &amp; time can be fully specified in a numeric
+format of year-month-dayThour:minute (e.g. 2000-12-31T23:59) in the local
+timezone. You may choose to separate the date numbers using slashes
+instead of dashes.</p>
+<p>The value can also be abbreviated in a variety of ways, such as specifying
+a 2-digit year and/or leaving off various values. In all cases, the value
+will be taken to be the next possible point in time where the supplied
+information matches. If the value specifies the current time or a past
+time, rsync exits with an error.</p>
+<p>For example, &quot;1-30&quot; specifies the next January 30th (at midnight local
+time), &quot;14:00&quot; specifies the next 2 P.M., &quot;1&quot; specifies the next 1st of the
+month at midnight, &quot;31&quot; specifies the next month where we can stop on its
+31st day, and &quot;:59&quot; specifies the next 59th minute after the hour.</p>
+<p>For maximal flexibility, rsync does not communicate this option to the
+remote rsync since it is usually enough that one side of the connection
+quits as specified. This allows the option's use even when only one side
+of the connection supports it. You can tell the remote side about the time
+limit using <a href="#opt--remote-option"><code>--remote-option</code></a> (<code>-M</code>), should the need arise. Do
+keep in mind that the remote host may have a different default timezone
+than your local host.</p>
+</dd>
+
+<dt id="opt--fsync"><code>--fsync</code><a href="#opt--fsync" class="tgt"></a></dt><dd>
+<p>Cause the receiving side to fsync each finished file. This may slow down
+the transfer, but can help to provide peace of mind when updating critical
+files.</p>
+</dd>
+
+<dt id="opt--write-batch"><code>--write-batch=FILE</code><a href="#opt--write-batch" class="tgt"></a></dt><dd>
+<p>Record a file that can later be applied to another identical destination
+with <a href="#opt--read-batch"><code>--read-batch</code></a>. See the &quot;BATCH MODE&quot; section for details, and
+also the <a href="#opt--only-write-batch"><code>--only-write-batch</code></a> option.</p>
+<p>This option overrides the negotiated checksum &amp; compress lists and always
+negotiates a choice based on old-school md5/md4/zlib choices. If you want
+a more modern choice, use the <a href="#opt--checksum-choice"><code>--checksum-choice</code></a> (<code>--cc</code>) and/or
+<a href="#opt--compress-choice"><code>--compress-choice</code></a> (<code>--zc</code>) options.</p>
+</dd>
+
+<dt id="opt--only-write-batch"><code>--only-write-batch=FILE</code><a href="#opt--only-write-batch" class="tgt"></a></dt><dd>
+<p>Works like <a href="#opt--write-batch"><code>--write-batch</code></a>, except that no updates are made on the
+destination system when creating the batch. This lets you transport the
+changes to the destination system via some other means and then apply the
+changes via <a href="#opt--read-batch"><code>--read-batch</code></a>.</p>
+<p>Note that you can feel free to write the batch directly to some portable
+media: if this media fills to capacity before the end of the transfer, you
+can just apply that partial transfer to the destination and repeat the
+whole process to get the rest of the changes (as long as you don't mind a
+partially updated destination system while the multi-update cycle is
+happening).</p>
+<p>Also note that you only save bandwidth when pushing changes to a remote
+system because this allows the batched data to be diverted from the sender
+into the batch file without having to flow over the wire to the receiver
+(when pulling, the sender is remote, and thus can't write the batch).</p>
+</dd>
+
+<dt id="opt--read-batch"><code>--read-batch=FILE</code><a href="#opt--read-batch" class="tgt"></a></dt><dd>
+<p>Apply all of the changes stored in FILE, a file previously generated by
+<a href="#opt--write-batch"><code>--write-batch</code></a>. If <u>FILE</u> is <code>-</code>, the batch data will be read
+from standard input. See the &quot;BATCH MODE&quot; section for details.</p>
+</dd>
+
+<dt id="opt--protocol"><code>--protocol=NUM</code><a href="#opt--protocol" class="tgt"></a></dt><dd>
+<p>Force an older protocol version to be used. This is useful for creating a
+batch file that is compatible with an older version of rsync. For
+instance, if rsync 2.6.4 is being used with the <a href="#opt--write-batch"><code>--write-batch</code></a>
+option, but rsync 2.6.3 is what will be used to run the
+<a href="#opt--read-batch"><code>--read-batch</code></a> option, you should use &quot;-&#8288;-&#8288;protocol=28&quot; when creating
+the batch file to force the older protocol version to be used in the batch
+file (assuming you can't upgrade the rsync on the reading system).</p>
+</dd>
+
+<dt id="opt--iconv"><code>--iconv=CONVERT_SPEC</code><a href="#opt--iconv" class="tgt"></a></dt><dd>
+<p>Rsync can convert filenames between character sets using this option.
+Using a CONVERT_SPEC of &quot;.&quot; tells rsync to look up the default
+character-set via the locale setting. Alternately, you can fully specify
+what conversion to do by giving a local and a remote charset separated by a
+comma in the order <code>--iconv=LOCAL,REMOTE</code>, e.g. <code>--iconv=utf8,iso88591</code>.
+This order ensures that the option will stay the same whether you're
+pushing or pulling files. Finally, you can specify either <code>--no-iconv</code> or
+a CONVERT_SPEC of &quot;-&#8288;&quot; to turn off any conversion. The default setting of
+this option is site-specific, and can also be affected via the
+<a href="#RSYNC_ICONV"><code>RSYNC_ICONV</code></a> environment variable.</p>
+<p>For a list of what charset names your local iconv library supports, you can
+run &quot;<code>iconv --list</code>&quot;.</p>
+<p>If you specify the <a href="#opt--secluded-args"><code>--secluded-args</code></a> (<code>-s</code>) option, rsync will
+translate the filenames you specify on the command-line that are being sent
+to the remote host. See also the <a href="#opt--files-from"><code>--files-from</code></a> option.</p>
+<p>Note that rsync does not do any conversion of names in filter files
+(including include/exclude files). It is up to you to ensure that you're
+specifying matching rules that can match on both sides of the transfer.
+For instance, you can specify extra include/exclude rules if there are
+filename differences on the two sides that need to be accounted for.</p>
+<p>When you pass an <code>--iconv</code> option to an rsync daemon that allows it, the
+daemon uses the charset specified in its &quot;charset&quot; configuration parameter
+regardless of the remote charset you actually pass. Thus, you may feel
+free to specify just the local charset for a daemon transfer (e.g.
+<code>--iconv=utf8</code>).</p>
+</dd>
+
+<span id="opt-6"></span><span id="opt--ipv6"></span><span id="opt-4"></span><dt id="opt--ipv4"><code>--ipv4</code>, <code>-4</code> or <code>--ipv6</code>, <code>-6</code><a href="#opt--ipv4" class="tgt"></a></dt><dd>
+<p>Tells rsync to prefer IPv4/IPv6 when creating sockets or running ssh. This
+affects sockets that rsync has direct control over, such as the outgoing
+socket when directly contacting an rsync daemon, as well as the forwarding
+of the <code>-4</code> or <code>-6</code> option to ssh when rsync can deduce that ssh is being
+used as the remote shell. For other remote shells you'll need to specify
+the &quot;<code>--rsh SHELL -4</code>&quot; option directly (or whatever IPv4/IPv6 hint options
+it uses).</p>
+<p>See also <a href="#dopt--ipv4">the daemon version of these options</a>.</p>
+<p>If rsync was compiled without support for IPv6, the <code>--ipv6</code> option will
+have no effect. The <code>rsync --version</code> output will contain &quot;<code>no IPv6</code>&quot; if
+is the case.</p>
+</dd>
+
+<dt id="opt--checksum-seed"><code>--checksum-seed=NUM</code><a href="#opt--checksum-seed" class="tgt"></a></dt><dd>
+<p>Set the checksum seed to the integer NUM. This 4 byte checksum seed is
+included in each block and MD4 file checksum calculation (the more modern
+MD5 file checksums don't use a seed). By default the checksum seed is
+generated by the server and defaults to the current <strong>time</strong>(). This
+option is used to set a specific checksum seed, which is useful for
+applications that want repeatable block checksums, or in the case where the
+user wants a more random checksum seed. Setting NUM to 0 causes rsync to
+use the default of <strong>time</strong>() for checksum seed.</p>
+</dd>
+</dl>
+<h2 id="DAEMON_OPTIONS">DAEMON OPTIONS<a href="#DAEMON_OPTIONS" class="tgt"></a></h2>
+<p>The options allowed when starting an rsync daemon are as follows:</p>
+<dl>
+
+<dt id="dopt--daemon"><code>--daemon</code><a href="#dopt--daemon" class="tgt"></a></dt><dd>
+<p>This tells rsync that it is to run as a daemon. The daemon you start
+running may be accessed using an rsync client using the <code>host::module</code> or
+<code>rsync://host/module/</code> syntax.</p>
+<p>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.</p>
+<p>See the <a href="rsyncd.conf.5"><strong>rsyncd.conf</strong>(5)</a> manpage for more details.</p>
+</dd>
+
+<dt id="dopt--address"><code>--address=ADDRESS</code><a href="#dopt--address" class="tgt"></a></dt><dd>
+<p>By default rsync will bind to the wildcard address when run as a daemon
+with the <code>--daemon</code> option. The <code>--address</code> option allows you to specify a
+specific IP address (or hostname) to bind to. This makes virtual hosting
+possible in conjunction with the <code>--config</code> option.</p>
+<p>See also the <a href="rsyncd.conf.5#address">address</a> global option in the
+rsyncd.conf manpage and the <a href="#opt--address">client version of the <code>--address</code>
+option</a>.</p>
+</dd>
+
+<dt id="dopt--bwlimit"><code>--bwlimit=RATE</code><a href="#dopt--bwlimit" class="tgt"></a></dt><dd>
+<p>This option allows you to specify the maximum transfer rate for the data
+the daemon sends over the socket. The client can still specify a smaller
+<code>--bwlimit</code> value, but no larger value will be allowed.</p>
+<p>See the <a href="#opt--bwlimit">client version of the <code>--bwlimit</code> option</a> for some
+extra details.</p>
+</dd>
+
+<dt id="dopt--config"><code>--config=FILE</code><a href="#dopt--config" class="tgt"></a></dt><dd>
+<p>This specifies an alternate config file than the default. This is only
+relevant when <a href="#dopt--daemon"><code>--daemon</code></a> is specified. The default is
+/etc/rsyncd.conf unless the daemon is running over a remote shell program
+and the remote user is not the super-user; in that case the default is
+rsyncd.conf in the current directory (typically $HOME).</p>
+</dd>
+
+<span id="dopt-M"></span><dt id="dopt--dparam"><code>--dparam=OVERRIDE</code>, <code>-M</code><a href="#dopt--dparam" class="tgt"></a></dt><dd>
+<p>This option can be used to set a daemon-config parameter when starting up
+rsync in daemon mode. It is equivalent to adding the parameter at the end
+of the global settings prior to the first module's definition. The
+parameter names can be specified without spaces, if you so desire. For
+instance:</p>
+<blockquote>
+<pre><code>rsync --daemon -M pidfile=/path/rsync.pid
+</code></pre>
+</blockquote>
+</dd>
+
+<dt id="dopt--no-detach"><code>--no-detach</code><a href="#dopt--no-detach" class="tgt"></a></dt><dd>
+<p>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 <code>daemontools</code> or AIX's <code>System Resource Controller</code>.
+<code>--no-detach</code> is also recommended when rsync is run under a debugger. This
+option has no effect if rsync is run from inetd or sshd.</p>
+</dd>
+
+<dt id="dopt--port"><code>--port=PORT</code><a href="#dopt--port" class="tgt"></a></dt><dd>
+<p>This specifies an alternate TCP port number for the daemon to listen on
+rather than the default of 873.</p>
+<p>See also <a href="#opt--port">the client version of the <code>--port</code> option</a> and the
+<a href="rsyncd.conf.5#port">port</a> global setting in the rsyncd.conf manpage.</p>
+</dd>
+
+<dt id="dopt--log-file"><code>--log-file=FILE</code><a href="#dopt--log-file" class="tgt"></a></dt><dd>
+<p>This option tells the rsync daemon to use the given log-file name instead
+of using the &quot;<code>log file</code>&quot; setting in the config file.</p>
+<p>See also <a href="#opt--log-file">the client version of the <code>--log-file</code> option</a>.</p>
+</dd>
+
+<dt id="dopt--log-file-format"><code>--log-file-format=FORMAT</code><a href="#dopt--log-file-format" class="tgt"></a></dt><dd>
+<p>This option tells the rsync daemon to use the given FORMAT string instead
+of using the &quot;<code>log format</code>&quot; setting in the config file. It also enables
+&quot;<code>transfer logging</code>&quot; unless the string is empty, in which case transfer
+logging is turned off.</p>
+<p>See also <a href="#opt--log-file-format">the client version of the <code>--log-file-format</code>
+option</a>.</p>
+</dd>
+
+<dt id="dopt--sockopts"><code>--sockopts</code><a href="#dopt--sockopts" class="tgt"></a></dt><dd>
+<p>This overrides the <a href="rsyncd.conf.5#socket_options"><code>socket options</code></a>
+setting in the rsyncd.conf file and has the same syntax.</p>
+<p>See also <a href="#opt--sockopts">the client version of the <code>--sockopts</code> option</a>.</p>
+</dd>
+
+<span id="dopt-v"></span><dt id="dopt--verbose"><code>--verbose</code>, <code>-v</code><a href="#dopt--verbose" class="tgt"></a></dt><dd>
+<p>This option increases the amount of information the daemon logs during its
+startup phase. After the client connects, the daemon's verbosity level
+will be controlled by the options that the client used and the
+&quot;<code>max verbosity</code>&quot; setting in the module's config section.</p>
+<p>See also <a href="#opt--verbose">the client version of the <code>--verbose</code> option</a>.</p>
+</dd>
+
+<span id="dopt-6"></span><span id="dopt--ipv6"></span><span id="dopt-4"></span><dt id="dopt--ipv4"><code>--ipv4</code>, <code>-4</code> or <code>--ipv6</code>, <code>-6</code><a href="#dopt--ipv4" class="tgt"></a></dt><dd>
+<p>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 &quot;address already in use&quot; error when nothing else is
+using the port, try specifying <code>--ipv6</code> or <code>--ipv4</code> when starting the
+daemon).</p>
+<p>See also <a href="#opt--ipv4">the client version of these options</a>.</p>
+<p>If rsync was compiled without support for IPv6, the <code>--ipv6</code> option will
+have no effect. The <code>rsync --version</code> output will contain &quot;<code>no IPv6</code>&quot; if
+is the case.</p>
+</dd>
+
+<span id="dopt-h"></span><dt id="dopt--help"><code>--help</code>, <code>-h</code><a href="#dopt--help" class="tgt"></a></dt><dd>
+<p>When specified after <code>--daemon</code>, print a short help page describing the
+options available for starting an rsync daemon.</p>
+</dd>
+</dl>
+<h2 id="FILTER_RULES">FILTER RULES<a href="#FILTER_RULES" class="tgt"></a></h2>
+<p>The filter rules allow for custom control of several aspects of how files are
+handled:</p>
+<ul>
+<li>Control which files the sending side puts into the file list that describes
+the transfer hierarchy</li>
+<li>Control which files the receiving side protects from deletion when the file
+is not in the sender's file list</li>
+<li>Control which extended attribute names are skipped when copying xattrs</li>
+</ul>
+<p>The rules are either directly specified via option arguments or they can be
+read in from one or more files. The filter-rule files can even be a part of
+the hierarchy of files being copied, affecting different parts of the tree in
+different ways.</p>
+<h3 id="SIMPLE_INCLUDE_EXCLUDE_RULES">SIMPLE INCLUDE/EXCLUDE RULES<a href="#SIMPLE_INCLUDE_EXCLUDE_RULES" class="tgt"></a></h3>
+<p>We will first cover the basics of how include &amp; exclude rules affect what files
+are transferred, ignoring any deletion side-effects. Filter rules mainly
+affect the contents of directories that rsync is &quot;recursing&quot; into, but they can
+also affect a top-level item in the transfer that was specified as a argument.</p>
+<p>The default for any unmatched file/dir is for it to be included in the
+transfer, which puts the file/dir into the sender's file list. The use of an
+exclude rule causes one or more matching files/dirs to be left out of the
+sender's file list. An include rule can be used to limit the effect of an
+exclude rule that is matching too many files.</p>
+<p>The order of the rules is important because the first rule that matches is the
+one that takes effect. Thus, if an early rule excludes a file, no include rule
+that comes after it can have any effect. This means that you must place any
+include overrides somewhere prior to the exclude that it is intended to limit.</p>
+<p>When a directory is excluded, all its contents and sub-contents are also
+excluded. The sender doesn't scan through any of it at all, which can save a
+lot of time when skipping large unneeded sub-trees.</p>
+<p>It is also important to understand that the include/exclude rules are applied
+to every file and directory that the sender is recursing into. Thus, if you
+want a particular deep file to be included, you have to make sure that none of
+the directories that must be traversed on the way down to that file are
+excluded or else the file will never be discovered to be included. As an
+example, if the directory &quot;<code>a/path</code>&quot; was given as a transfer argument and you
+want to ensure that the file &quot;<code>a/path/down/deep/wanted.txt</code>&quot; is a part of the
+transfer, then the sender must not exclude the directories &quot;<code>a/path</code>&quot;,
+&quot;<code>a/path/down</code>&quot;, or &quot;<code>a/path/down/deep</code>&quot; as it makes it way scanning through
+the file tree.</p>
+<p>When you are working on the rules, it can be helpful to ask rsync to tell you
+what is being excluded/included and why. Specifying <code>--debug=FILTER</code> or (when
+pulling files) <code>-M--debug=FILTER</code> turns on level 1 of the FILTER debug
+information that will output a message any time that a file or directory is
+included or excluded and which rule it matched. Beginning in 3.2.4 it will
+also warn if a filter rule has trailing whitespace, since an exclude of &quot;foo&nbsp;&quot;
+(with a trailing space) will not exclude a file named &quot;foo&quot;.</p>
+<p>Exclude and include rules can specify wildcard <a href="#PATTERN_MATCHING_RULES">PATTERN MATCHING RULES</a>
+(similar to shell wildcards) that allow you to match things like a file suffix
+or a portion of a filename.</p>
+<p>A rule can be limited to only affecting a directory by putting a trailing slash
+onto the filename.</p>
+<h3 id="SIMPLE_INCLUDE_EXCLUDE_EXAMPLE">SIMPLE INCLUDE/EXCLUDE EXAMPLE<a href="#SIMPLE_INCLUDE_EXCLUDE_EXAMPLE" class="tgt"></a></h3>
+<p>With the following file tree created on the sending side:</p>
+<blockquote>
+<pre><code>mkdir x/
+touch x/file.txt
+mkdir x/y/
+touch x/y/file.txt
+touch x/y/zzz.txt
+mkdir x/z/
+touch x/z/file.txt
+</code></pre>
+</blockquote>
+<p>Then the following rsync command will transfer the file &quot;<code>x/y/file.txt</code>&quot; and
+the directories needed to hold it, resulting in the path &quot;<code>/tmp/x/y/file.txt</code>&quot;
+existing on the remote host:</p>
+<blockquote>
+<pre><code>rsync -ai -f'+ x/' -f'+ x/y/' -f'+ x/y/file.txt' -f'- *' x host:/tmp/
+</code></pre>
+</blockquote>
+<p>Aside: this copy could also have been accomplished using the <a href="#opt-R"><code>-R</code></a>
+option (though the 2 commands behave differently if deletions are enabled):</p>
+<blockquote>
+<pre><code>rsync -aiR x/y/file.txt host:/tmp/
+</code></pre>
+</blockquote>
+<p>The following command does not need an include of the &quot;x&quot; directory because it
+is not a part of the transfer (note the traililng slash). Running this command
+would copy just &quot;<code>/tmp/x/file.txt</code>&quot; because the &quot;y&quot; and &quot;z&quot; dirs get excluded:</p>
+<blockquote>
+<pre><code>rsync -ai -f'+ file.txt' -f'- *' x/ host:/tmp/x/
+</code></pre>
+</blockquote>
+<p>This command would omit the zzz.txt file while copying &quot;x&quot; and everything else
+it contains:</p>
+<blockquote>
+<pre><code>rsync -ai -f'- zzz.txt' x host:/tmp/
+</code></pre>
+</blockquote>
+<h3 id="FILTER_RULES_WHEN_DELETING">FILTER RULES WHEN DELETING<a href="#FILTER_RULES_WHEN_DELETING" class="tgt"></a></h3>
+<p>By default the include &amp; exclude filter rules affect both the sender
+(as it creates its file list)
+and the receiver (as it creates its file lists for calculating deletions). If
+no delete option is in effect, the receiver skips creating the delete-related
+file lists. This two-sided default can be manually overridden so that you are
+only specifying sender rules or receiver rules, as described in the <a href="#FILTER_RULES_IN_DEPTH">FILTER
+RULES IN DEPTH</a> section.</p>
+<p>When deleting, an exclude protects a file from being removed on the receiving
+side while an include overrides that protection (putting the file at risk of
+deletion). The default is for a file to be at risk&nbsp;-&#8288;-&#8288; its safety depends on it
+matching a corresponding file from the sender.</p>
+<p>An example of the two-sided exclude effect can be illustrated by the copying of
+a C development directory between 2 systems. When doing a touch-up copy, you
+might want to skip copying the built executable and the <code>.o</code> files (sender
+hide) so that the receiving side can build their own and not lose any object
+files that are already correct (receiver protect). For instance:</p>
+<blockquote>
+<pre><code>rsync -ai --del -f'- *.o' -f'- cmd' src host:/dest/
+</code></pre>
+</blockquote>
+<p>Note that using <code>-f'-p *.o'</code> is even better than <code>-f'- *.o'</code> if there is a
+chance that the directory structure may have changed. The &quot;p&quot; modifier is
+discussed in <a href="#FILTER_RULE_MODIFIERS">FILTER RULE MODIFIERS</a>.</p>
+<p>One final note, if your shell doesn't mind unexpanded wildcards, you could
+simplify the typing of the filter options by using an underscore in place of
+the space and leaving off the quotes. For instance, <code>-f -_*.o -f -_cmd</code> (and
+similar) could be used instead of the filter options above.</p>
+<h3 id="FILTER_RULES_IN_DEPTH">FILTER RULES IN DEPTH<a href="#FILTER_RULES_IN_DEPTH" class="tgt"></a></h3>
+<p>Rsync supports old-style include/exclude rules and new-style filter rules. The
+older rules are specified using <a href="#opt--include"><code>--include</code></a> and <a href="#opt--exclude"><code>--exclude</code></a> as
+well as the <a href="#opt--include-from"><code>--include-from</code></a> and <a href="#opt--exclude-from"><code>--exclude-from</code></a>. These are
+limited in behavior but they don't require a &quot;-&#8288;&quot; or &quot;+&quot; prefix. An old-style
+exclude rule is turned into a &quot;<code>- name</code>&quot; filter rule (with no modifiers) and an
+old-style include rule is turned into a &quot;<code>+ name</code>&quot; filter rule (with no
+modifiers).</p>
+<p>Rsync builds an ordered list of filter rules as specified on the command-line
+and/or read-in from files. New style filter rules have the following syntax:</p>
+<blockquote>
+<pre><code>RULE [PATTERN_OR_FILENAME]
+RULE,MODIFIERS [PATTERN_OR_FILENAME]
+</code></pre>
+</blockquote>
+<p>You have your choice of using either short or long RULE names, as described
+below. If you use a short-named rule, the ',' separating the RULE from the
+MODIFIERS is optional. The PATTERN or FILENAME that follows (when present)
+must come after either a single space or an underscore (_). Any additional
+spaces and/or underscores are considered to be a part of the pattern name.
+Here are the available rule prefixes:</p>
+<dl>
+<dt><code>exclude, '-'</code></dt><dd> specifies an exclude pattern that (by default) is both a
+<code>hide</code> and a <code>protect</code>.</dd>
+<dt><code>include, '+'</code></dt><dd> specifies an include pattern that (by default) is both a
+<code>show</code> and a <code>risk</code>.</dd>
+<dt><code>merge, '.'</code></dt><dd> specifies a merge-file on the client side to read for more
+rules.</dd>
+<dt><code>dir-merge, ':'</code></dt><dd> specifies a per-directory merge-file. Using this kind of
+filter rule requires that you trust the sending side's filter checking, so
+it has the side-effect mentioned under the <a href="#opt--trust-sender"><code>--trust-sender</code></a> option.</dd>
+<dt><code>hide, 'H'</code></dt><dd> specifies a pattern for hiding files from the transfer.
+Equivalent to a sender-only exclude, so <code>-f'H foo'</code> could also be specified
+as <code>-f'-s foo'</code>.</dd>
+<dt><code>show, 'S'</code></dt><dd> files that match the pattern are not hidden. Equivalent to a
+sender-only include, so <code>-f'S foo'</code> could also be specified as <code>-f'+s foo'</code>.</dd>
+<dt><code>protect, 'P'</code></dt><dd> specifies a pattern for protecting files from deletion.
+Equivalent to a receiver-only exclude, so <code>-f'P foo'</code> could also be
+specified as <code>-f'-r foo'</code>.</dd>
+<dt><code>risk, 'R'</code></dt><dd> files that match the pattern are not protected. Equivalent to a
+receiver-only include, so <code>-f'R foo'</code> could also be specified as <code>-f'+r foo'</code>.</dd>
+<dt><code>clear, '!'</code></dt><dd> clears the current include/exclude list (takes no arg)</dd>
+</dl>
+<p>When rules are being read from a file (using merge or dir-merge), empty lines
+are ignored, as are whole-line comments that start with a '<code>#</code>' (filename rules
+that contain a hash character are unaffected).</p>
+<p>Note also that the <a href="#opt--filter"><code>--filter</code></a>, <a href="#opt--include"><code>--include</code></a>, and
+<a href="#opt--exclude"><code>--exclude</code></a> 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 <a href="#opt--filter"><code>--filter</code></a> option, or the <a href="#opt--include-from"><code>--include-from</code></a> /
+<a href="#opt--exclude-from"><code>--exclude-from</code></a> options.</p>
+<h3 id="PATTERN_MATCHING_RULES">PATTERN MATCHING RULES<a href="#PATTERN_MATCHING_RULES" class="tgt"></a></h3>
+<p>Most of the rules mentioned above take an argument that specifies what the rule
+should match. If rsync is recursing through a directory hierarchy, keep in
+mind that each pattern is matched against the name of every directory in the
+descent path as rsync finds the filenames to send.</p>
+<p>The matching rules for the pattern argument take several forms:</p>
+<ul>
+<li>If a pattern contains a <code>/</code> (not counting a trailing slash) or a &quot;<code>**</code>&quot;
+(which can match a slash), then the pattern is matched against the full
+pathname, including any leading directories within the transfer. If the
+pattern doesn't contain a (non-trailing) <code>/</code> or a &quot;<code>**</code>&quot;, then it is matched
+only against the final component of the filename or pathname. For example,
+<code>foo</code> means that the final path component must be &quot;foo&quot; while <code>foo/bar</code> would
+match the last 2 elements of the path (as long as both elements are within
+the transfer).</li>
+<li>A pattern that ends with a <code>/</code> only matches a directory, not a regular file,
+symlink, or device.</li>
+<li>A pattern that starts with a <code>/</code> is anchored to the start of the transfer
+path instead of the end. For example, <code>/foo/**</code> or <code>/foo/bar/**</code> match only
+leading elements in the path. If the rule is read from a per-directory
+filter file, the transfer path being matched will begin at the level of the
+filter file instead of the top of the transfer. See the section on
+<a href="#ANCHORING_INCLUDE_EXCLUDE_PATTERNS">ANCHORING INCLUDE/EXCLUDE PATTERNS</a> for a full discussion of how to
+specify a pattern that matches at the root of the transfer.</li>
+</ul>
+<p>Rsync chooses between doing a simple string match and wildcard matching by
+checking if the pattern contains one of these three wildcard characters: '<code>*</code>',
+'<code>?</code>', and '<code>[</code>' :</p>
+<ul>
+<li>a '<code>?</code>' matches any single character except a slash (<code>/</code>).</li>
+<li>a '<code>*</code>' matches zero or more non-slash characters.</li>
+<li>a '<code>**</code>' matches zero or more characters, including slashes.</li>
+<li>a '<code>[</code>' introduces a character class, such as <code>[a-z]</code> or <code>[[:alpha:]]</code>, that
+must match one character.</li>
+<li>a trailing <code>***</code> in the pattern is a shorthand that allows you to match a
+directory and all its contents using a single rule. For example, specifying
+&quot;<code>dir_name/***</code>&quot; will match both the &quot;dir_name&quot; directory (as if &quot;<code>dir_name/</code>&quot;
+had been specified) and everything in the directory (as if &quot;<code>dir_name/**</code>&quot;
+had been specified).</li>
+<li>a backslash can be used to escape a wildcard character, but it is only
+interpreted as an escape character if at least one wildcard character is
+present in the match pattern. For instance, the pattern &quot;<code>foo\bar</code>&quot; matches
+that single backslash literally, while the pattern &quot;<code>foo\bar*</code>&quot; would need to
+be changed to &quot;<code>foo\\bar*</code>&quot; to avoid the &quot;<code>\b</code>&quot; becoming just &quot;b&quot;.</li>
+</ul>
+<p>Here are some examples of exclude/include matching:</p>
+<ul>
+<li>Option <code>-f'- *.o'</code> would exclude all filenames ending with <code>.o</code></li>
+<li>Option <code>-f'- /foo'</code> would exclude a file (or directory) named foo in the
+transfer-root directory</li>
+<li>Option <code>-f'- foo/'</code> would exclude any directory named foo</li>
+<li>Option <code>-f'- foo/*/bar'</code> would exclude any file/dir named bar which is at two
+levels below a directory named foo (if foo is in the transfer)</li>
+<li>Option <code>-f'- /foo/**/bar'</code> would exclude any file/dir named bar that was two
+or more levels below a top-level directory named foo (note that /foo/bar is
+<strong>not</strong> excluded by this)</li>
+<li>Options <code>-f'+ */' -f'+ *.c' -f'- *'</code> would include all directories and .c
+source files but nothing else</li>
+<li>Options <code>-f'+ foo/' -f'+ foo/bar.c' -f'- *'</code> would include only the foo
+directory and foo/bar.c (the foo directory must be explicitly included or it
+would be excluded by the &quot;<code>- *</code>&quot;)</li>
+</ul>
+<h3 id="FILTER_RULE_MODIFIERS">FILTER RULE MODIFIERS<a href="#FILTER_RULE_MODIFIERS" class="tgt"></a></h3>
+<p>The following modifiers are accepted after an include (+) or exclude (-&#8288;) rule:</p>
+<ul>
+<li>A <code>/</code> specifies that the include/exclude rule should be matched against the
+absolute pathname of the current item. For example, <code>-f'-/ /etc/passwd'</code>
+would exclude the passwd file any time the transfer was sending files from
+the &quot;/etc&quot; directory, and &quot;-&#8288;/ subdir/foo&quot; would always exclude &quot;foo&quot; when it
+is in a dir named &quot;subdir&quot;, even if &quot;foo&quot; is at the root of the current
+transfer.</li>
+<li>A <code>!</code> specifies that the include/exclude should take effect if the pattern
+fails to match. For instance, <code>-f'-! */'</code> would exclude all non-directories.</li>
+<li>A <code>C</code> is used to indicate that all the global CVS-exclude rules should be
+inserted as excludes in place of the &quot;-&#8288;C&quot;. No arg should follow.</li>
+<li>An <code>s</code> is used to indicate that the rule applies to the sending side. When a
+rule affects the sending side, it affects what files are put into the
+sender's file list. The default is for a rule to affect both sides unless
+<a href="#opt--delete-excluded"><code>--delete-excluded</code></a> was specified, in which case default rules become
+sender-side only. See also the hide (H) and show (S) rules, which are an
+alternate way to specify sending-side includes/excludes.</li>
+<li>An <code>r</code> is used to indicate that the rule applies to the receiving side. When
+a rule affects the receiving side, it prevents files from being deleted. See
+the <code>s</code> modifier for more info. See also the protect (P) and risk (R) rules,
+which are an alternate way to specify receiver-side includes/excludes.</li>
+<li>A <code>p</code> indicates that a rule is perishable, meaning that it is ignored in
+directories that are being deleted. For instance, the
+<a href="#opt--cvs-exclude"><code>--cvs-exclude</code></a> (<code>-C</code>) option's default rules that exclude things
+like &quot;CVS&quot; and &quot;<code>*.o</code>&quot; are marked as perishable, and will not prevent a
+directory that was removed on the source from being deleted on the
+destination.</li>
+<li>An <code>x</code> indicates that a rule affects xattr names in xattr copy/delete
+operations (and is thus ignored when matching file/dir names). If no
+xattr-matching rules are specified, a default xattr filtering rule is used
+(see the <a href="#opt--xattrs"><code>--xattrs</code></a> option).</li>
+</ul>
+<h3 id="MERGE-FILE_FILTER_RULES">MERGE-FILE FILTER RULES<a href="#MERGE-FILE_FILTER_RULES" class="tgt"></a></h3>
+<p>You can merge whole files into your filter rules by specifying either a merge
+(.) or a dir-merge (:) filter rule (as introduced in the <a href="#FILTER_RULES">FILTER RULES</a>
+section above).</p>
+<p>There are two kinds of merged files&nbsp;-&#8288;-&#8288; 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 &quot;.&quot; 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 <a href="#PER-DIRECTORY_RULES_AND_DELETE">PER-DIRECTORY RULES AND DELETE</a> below).</p>
+<p>Some examples:</p>
+<blockquote>
+<pre><code>merge /etc/rsync/default.rules
+. /etc/rsync/default.rules
+dir-merge .per-dir-filter
+dir-merge,n- .non-inherited-per-dir-excludes
+:n- .non-inherited-per-dir-excludes
+</code></pre>
+</blockquote>
+<p>The following modifiers are accepted after a merge or dir-merge rule:</p>
+<ul>
+<li>A <code>-</code> specifies that the file should consist of only exclude patterns, with
+no other rule-parsing except for in-file comments.</li>
+<li>A <code>+</code> specifies that the file should consist of only include patterns, with
+no other rule-parsing except for in-file comments.</li>
+<li>A <code>C</code> is a way to specify that the file should be read in a CVS-compatible
+manner. This turns on 'n', 'w', and '-&#8288;', but also allows the list-clearing
+token (!) to be specified. If no filename is provided, &quot;.cvsignore&quot; is
+assumed.</li>
+<li>A <code>e</code> will exclude the merge-file name from the transfer; e.g. &quot;dir-merge,e
+.rules&quot; is like &quot;dir-merge .rules&quot; and &quot;-&#8288; .rules&quot;.</li>
+<li>An <code>n</code> specifies that the rules are not inherited by subdirectories.</li>
+<li>A <code>w</code> specifies that the rules are word-split on 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 &quot;-&#8288; foo + bar&quot; is
+parsed as two rules (assuming that prefix-parsing wasn't also disabled).</li>
+<li>You may also specify any of the modifiers for the &quot;+&quot; or &quot;-&#8288;&quot; rules (above) in
+order to have the rules that are read in from the file default to having that
+modifier set (except for the <code>!</code> modifier, which would not be useful). For
+instance, &quot;merge,-&#8288;/ .excl&quot; would treat the contents of .excl as absolute-path
+excludes, while &quot;dir-merge,s .filt&quot; and &quot;:sC&quot; would each make all their
+per-directory rules apply only on the sending side. If the merge rule
+specifies sides to affect (via the <code>s</code> or <code>r</code> modifier or both), then the
+rules in the file must not specify sides (via a modifier or a rule prefix
+such as <code>hide</code>).</li>
+</ul>
+<p>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 dir-merge rules are grouped together in the spot where the merge-file
+was specified, so it is possible to override dir-merge rules via a rule that
+got specified earlier in the list of global rules. When the list-clearing rule
+(&quot;!&quot;) is read from a per-directory file, it only clears the inherited rules for
+the current merge file.</p>
+<p>Another way to prevent a single rule from a dir-merge file 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 &quot;/foo&quot;
+would only match the file &quot;foo&quot; in the directory where the dir-merge filter
+file was found.</p>
+<p>Here's an example filter file which you'd specify via <code>--filter=&quot;. file&quot;:</code></p>
+<blockquote>
+<pre><code>merge /home/user/.global-filter
+- *.gz
+dir-merge .rules
++ *.[ch]
+- *.o
+- foo*
+</code></pre>
+</blockquote>
+<p>This will merge the contents of the /home/user/.global-filter file at the start
+of the list and also turns the &quot;.rules&quot; 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).</p>
+<p>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 <a href="#opt-F"><code>-F</code></a>):</p>
+<blockquote>
+<pre><code>--filter=': /.rsync-filter'
+</code></pre>
+</blockquote>
+<p>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 &quot;path&quot;.)</p>
+<p>Some examples of this pre-scanning for per-directory files:</p>
+<blockquote>
+<pre><code>rsync -avF /src/path/ /dest/dir
+rsync -av --filter=': ../../.rsync-filter' /src/path/ /dest/dir
+rsync -av --filter=': .rsync-filter' /src/path/ /dest/dir
+</code></pre>
+</blockquote>
+<p>The first two commands above will look for &quot;.rsync-filter&quot; in &quot;/&quot; and &quot;/src&quot;
+before the normal scan begins looking for the file in &quot;/src/path&quot; and its
+subdirectories. The last command avoids the parent-dir scan and only looks for
+the &quot;.rsync-filter&quot; files in each directory that is a part of the transfer.</p>
+<p>If you want to include the contents of a &quot;.cvsignore&quot; in your patterns, you
+should use the rule &quot;:C&quot;, which creates a dir-merge of the .cvsignore file, but
+parsed in a CVS-compatible manner. You can use this to affect where the
+<a href="#opt--cvs-exclude"><code>--cvs-exclude</code></a> (<code>-C</code>) option's inclusion of the per-directory
+.cvsignore file gets placed into your rules by putting the &quot;:C&quot; wherever you
+like in your filter rules. Without this, rsync would add the dir-merge rule
+for the .cvsignore file at the end of all your other rules (giving it a lower
+priority than your command-line rules). For example:</p>
+<blockquote>
+<pre><code>cat &lt;&lt;EOT | rsync -avC --filter='. -' a/ b
++ foo.o
+:C
+- *.old
+EOT
+rsync -avC --include=foo.o -f :C --exclude='*.old' a/ b
+</code></pre>
+</blockquote>
+<p>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. To affect the other CVS
+exclude rules (i.e. the default list of exclusions, the contents of
+$HOME/.cvsignore, and the value of $CVSIGNORE) you should omit the <code>-C</code>
+command-line option and instead insert a &quot;-&#8288;C&quot; rule into your filter rules; e.g.
+&quot;<code>--filter=-C</code>&quot;.</p>
+<h3 id="LIST-CLEARING_FILTER_RULE">LIST-CLEARING FILTER RULE<a href="#LIST-CLEARING_FILTER_RULE" class="tgt"></a></h3>
+<p>You can clear the current include/exclude list by using the &quot;!&quot; filter rule (as
+introduced in the <a href="#FILTER_RULES">FILTER RULES</a> section above). The &quot;current&quot; 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).</p>
+<h3 id="ANCHORING_INCLUDE_EXCLUDE_PATTERNS">ANCHORING INCLUDE/EXCLUDE PATTERNS<a href="#ANCHORING_INCLUDE_EXCLUDE_PATTERNS" class="tgt"></a></h3>
+<p>As mentioned earlier, global include/exclude patterns are anchored at the &quot;root
+of the transfer&quot; (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.</p>
+<p>Because the matching is relative to the transfer-root, changing the trailing
+slash on a source path or changing your use of the <a href="#opt--relative"><code>--relative</code></a> 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.</p>
+<p>Let's say that we want to match two source files, one with an absolute
+path of &quot;/home/me/foo/bar&quot;, and one with a path of &quot;/home/you/bar/baz&quot;.
+Here is how the various command choices differ for a 2-source transfer:</p>
+<blockquote>
+<pre><code>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
+</code></pre>
+</blockquote>
+<blockquote>
+<pre><code>Example cmd: rsync -a /home/me/ /home/you/ /dest
++/- pattern: /foo/bar (note missing &quot;me&quot;)
++/- pattern: /bar/baz (note missing &quot;you&quot;)
+Target file: /dest/foo/bar
+Target file: /dest/bar/baz
+</code></pre>
+</blockquote>
+<blockquote>
+<pre><code>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
+</code></pre>
+</blockquote>
+<blockquote>
+<pre><code>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
+</code></pre>
+</blockquote>
+<p>The easiest way to see what name you should filter is to just look at the
+output when using <a href="#opt--verbose"><code>--verbose</code></a> and put a / in front of the name (use the
+<code>--dry-run</code> option if you're not yet ready to copy any files).</p>
+<h3 id="PER-DIRECTORY_RULES_AND_DELETE">PER-DIRECTORY RULES AND DELETE<a href="#PER-DIRECTORY_RULES_AND_DELETE" class="tgt"></a></h3>
+<p>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:</p>
+<blockquote>
+<pre><code>rsync -av --filter=': .excl' --exclude=.excl host:src/dir /dest
+rsync -av --filter=':e .excl' host:src/dir /dest
+</code></pre>
+</blockquote>
+<p>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 <a href="#opt--delete-after"><code>--delete-after</code></a>,
+because this ensures that the receiving side gets all the same exclude rules as
+the sending side before it tries to delete anything:</p>
+<blockquote>
+<pre><code>rsync -avF --delete-after host:src/dir /dest
+</code></pre>
+</blockquote>
+<p>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):</p>
+<blockquote>
+<pre><code>rsync -av --filter=': .rules' --filter='. /my/extra.rules'
+ --delete host:src/dir /dest
+</code></pre>
+</blockquote>
+<p>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.</p>
+<p>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:</p>
+<blockquote>
+<pre><code>rsync -av --filter=':e /.rsync-filter' --delete \
+ host:src/dir /dest
+rsync -avFF --delete host:src/dir /dest
+</code></pre>
+</blockquote>
+<h2 id="TRANSFER_RULES">TRANSFER RULES<a href="#TRANSFER_RULES" class="tgt"></a></h2>
+<p>In addition to the <a href="#FILTER_RULES">FILTER RULES</a> that affect the recursive file scans that
+generate the file list on the sending and (when deleting) receiving sides,
+there are transfer rules. These rules affect which files the generator decides
+need to be transferred without the side effects of an exclude filter rule.
+Transfer rules affect only files and never directories.</p>
+<p>Because a transfer rule does not affect what goes into the sender's (and
+receiver's) file list, it cannot have any effect on which files get deleted on
+the receiving side. For example, if the file &quot;foo&quot; is present in the sender's
+list but its size is such that it is omitted due to a transfer rule, the
+receiving side does not request the file. However, its presence in the file
+list means that a delete pass will not remove a matching file named &quot;foo&quot; on
+the receiving side. On the other hand, a server-side exclude (hide) of the
+file &quot;foo&quot; leaves the file out of the server's file list, and absent a
+receiver-side exclude (protect) the receiver will remove a matching file named
+&quot;foo&quot; if deletions are requested.</p>
+<p>Given that the files are still in the sender's file list, the
+<a href="#opt--prune-empty-dirs"><code>--prune-empty-dirs</code></a> option will not judge a directory as being empty
+even if it contains only files that the transfer rules omitted.</p>
+<p>Similarly, a transfer rule does not have any extra effect on which files are
+deleted on the receiving side, so setting a maximum file size for the transfer
+does not prevent big files from being deleted.</p>
+<p>Examples of transfer rules include the default &quot;quick check&quot; algorithm (which
+compares size &amp; modify time), the <a href="#opt--update"><code>--update</code></a> option, the
+<a href="#opt--max-size"><code>--max-size</code></a> option, the <a href="#opt--ignore-non-existing"><code>--ignore-non-existing</code></a> option, and a
+few others.</p>
+<h2 id="BATCH_MODE">BATCH MODE<a href="#BATCH_MODE" class="tgt"></a></h2>
+<p>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 &quot;batch file&quot; all the information needed to repeat
+this operation against other, identical destination trees.</p>
+<p>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.</p>
+<p>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.</p>
+<p>For your convenience, a script file is also created when the write-batch option
+is used: it will be named the same as the batch file with &quot;.sh&quot; appended. This
+script file contains a command-line suitable for updating a destination tree
+using the associated batch file. It can be executed using a Bourne (or
+Bourne-like) shell, optionally passing in an alternate destination tree
+pathname which is then used instead of the original destination path. This is
+useful when the destination tree path on the current host differs from the one
+used to create the batch file.</p>
+<p>Examples:</p>
+<blockquote>
+<pre><code>$ rsync --write-batch=foo -a host:/source/dir/ /adest/dir/
+$ scp foo* remote:
+$ ssh remote ./foo.sh /bdest/dir/
+</code></pre>
+</blockquote>
+<blockquote>
+<pre><code>$ rsync --write-batch=foo -a /source/dir/ /adest/dir/
+$ ssh remote rsync --read-batch=- -a /bdest/dir/ &lt;foo
+</code></pre>
+</blockquote>
+<p>In these examples, rsync is used to update /adest/dir/ from /source/dir/ and
+the information to repeat this operation is stored in &quot;foo&quot; and &quot;foo.sh&quot;. The
+host &quot;remote&quot; 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:</p>
+<ul>
+<li>The first example shows that the initial copy doesn't have to be local&nbsp;-&#8288;-&#8288; you
+can push or pull data to/from a remote host using either the remote-shell
+syntax or rsync daemon syntax, as desired.</li>
+<li>The first example uses the created &quot;foo.sh&quot; file to get the right rsync
+options when running the read-batch command on the remote host.</li>
+<li>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
+<a href="#opt--read-batch"><code>--read-batch</code></a> 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 <a href="#opt--exclude-from"><code>--exclude-from=-</code></a> option).</li>
+</ul>
+<p>Caveats:</p>
+<p>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 a warning (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 <a href="#opt-I"><code>-I</code></a> 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.</p>
+<p>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.
+See also the <a href="#opt--protocol"><code>--protocol</code></a> option for a way to have the creating rsync
+generate a batch file that an older rsync can understand. (Note that batch
+files changed format in version 2.6.3, so mixing versions older than that with
+newer versions will not work.)</p>
+<p>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 <a href="#opt--write-batch"><code>--write-batch</code></a> changes to <a href="#opt--read-batch"><code>--read-batch</code></a>,
+<a href="#opt--files-from"><code>--files-from</code></a> is dropped, and the <a href="#opt--filter"><code>--filter</code></a> /
+<a href="#opt--include"><code>--include</code></a> / <a href="#opt--exclude"><code>--exclude</code></a> options are not needed unless one of
+the <a href="#opt--delete"><code>--delete</code></a> options is specified.</p>
+<p>The code that creates the BATCH.sh file transforms any filter/include/exclude
+options into a single list that is appended as a &quot;here&quot; 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 <a href="#opt--delete"><code>--delete</code></a> is desired. A normal user
+can ignore this detail and just use the shell script as an easy way to run the
+appropriate <a href="#opt--read-batch"><code>--read-batch</code></a> command for the batched data.</p>
+<p>The original batch mode in rsync was based on &quot;rsync+&quot;, but the latest
+version uses a new implementation.</p>
+<h2 id="SYMBOLIC_LINKS">SYMBOLIC LINKS<a href="#SYMBOLIC_LINKS" class="tgt"></a></h2>
+<p>Three basic behaviors are possible when rsync encounters a symbolic
+link in the source directory.</p>
+<p>By default, symbolic links are not transferred at all. A message &quot;skipping
+non-regular&quot; file is emitted for any symlinks that exist.</p>
+<p>If <a href="#opt--links"><code>--links</code></a> is specified, then symlinks are added to the transfer
+(instead of being noisily ignored), and the default handling is to recreate
+them with the same target on the destination. Note that <a href="#opt--archive"><code>--archive</code></a>
+implies <a href="#opt--links"><code>--links</code></a>.</p>
+<p>If <a href="#opt--copy-links"><code>--copy-links</code></a> is specified, then symlinks are &quot;collapsed&quot; by
+copying their referent, rather than the symlink.</p>
+<p>Rsync can also distinguish &quot;safe&quot; and &quot;unsafe&quot; symbolic links. An example
+where this might be used is a web site mirror that wishes to ensure that the
+rsync module that is copied does not include symbolic links to <code>/etc/passwd</code> in
+the public section of the site. Using <a href="#opt--copy-unsafe-links"><code>--copy-unsafe-links</code></a> will cause
+any links to be copied as the file they point to on the destination. Using
+<a href="#opt--safe-links"><code>--safe-links</code></a> will cause unsafe links to be omitted by the receiver.
+(Note that you must specify or imply <a href="#opt--links"><code>--links</code></a> for
+<a href="#opt--safe-links"><code>--safe-links</code></a> to have any effect.)</p>
+<p>Symbolic links are considered unsafe if they are absolute symlinks (start with
+<code>/</code>), empty, or if they contain enough &quot;..&quot; components to ascend from the top
+of the transfer.</p>
+<p>Here's a summary of how the symlink options are interpreted. The list is in
+order of precedence, so if your combination of options isn't mentioned, use the
+first line that is a complete subset of your options:</p>
+<dl>
+<dt><code>--copy-links</code></dt><dd> Turn all symlinks into normal files and directories
+(leaving no symlinks in the transfer for any other options to affect).</dd>
+<dt><code>--copy-dirlinks</code></dt><dd> Turn just symlinks to directories into real
+directories, leaving all other symlinks to be handled as described below.</dd>
+<dt><code>--links --copy-unsafe-links</code></dt><dd> Turn all unsafe symlinks
+into files and create all safe symlinks.</dd>
+<dt><code>--copy-unsafe-links</code></dt><dd> Turn all unsafe symlinks into files, noisily
+skip all safe symlinks.</dd>
+<dt><code>--links --safe-links</code></dt><dd> The receiver skips creating
+unsafe symlinks found in the transfer and creates the safe ones.</dd>
+<dt><code>--links</code></dt><dd> Create all symlinks.</dd>
+</dl>
+<p>For the effect of <a href="#opt--munge-links"><code>--munge-links</code></a>, see the discussion in that option's
+section.</p>
+<p>Note that the <a href="#opt--keep-dirlinks"><code>--keep-dirlinks</code></a> option does not effect symlinks in the
+transfer but instead affects how rsync treats a symlink to a directory that
+already exists on the receiving side. See that option's section for a warning.</p>
+<h2 id="DIAGNOSTICS">DIAGNOSTICS<a href="#DIAGNOSTICS" class="tgt"></a></h2>
+<p>Rsync occasionally produces error messages that may seem a little cryptic. The
+one that seems to cause the most confusion is &quot;protocol version mismatch&nbsp;-&#8288;-&#8288; is
+your shell clean?&quot;.</p>
+<p>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:</p>
+<blockquote>
+<pre><code>ssh remotehost /bin/true &gt; out.dat
+</code></pre>
+</blockquote>
+<p>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.</p>
+<p>If you are having trouble debugging filter patterns, then try specifying the
+<code>-vv</code> option. At this level of verbosity rsync will show why each individual
+file is included or excluded.</p>
+<h2 id="EXIT_VALUES">EXIT VALUES<a href="#EXIT_VALUES" class="tgt"></a></h2>
+<ul>
+<li><strong>0</strong> -&#8288; Success</li>
+<li><strong>1</strong> -&#8288; Syntax or usage error</li>
+<li><strong>2</strong> -&#8288; Protocol incompatibility</li>
+<li><strong>3</strong> -&#8288; Errors selecting input/output files, dirs</li>
+<li><strong>4</strong> -&#8288; Requested action not supported. Either:
+<ul>
+<li>an attempt was made to manipulate 64-bit files on a platform that cannot support them</li>
+<li>an option was specified that is supported by the client and not by the server</li>
+</ul>
+</li>
+<li><strong>5</strong> -&#8288; Error starting client-server protocol</li>
+<li><strong>6</strong> -&#8288; Daemon unable to append to log-file</li>
+<li><strong>10</strong> -&#8288; Error in socket I/O</li>
+<li><strong>11</strong> -&#8288; Error in file I/O</li>
+<li><strong>12</strong> -&#8288; Error in rsync protocol data stream</li>
+<li><strong>13</strong> -&#8288; Errors with program diagnostics</li>
+<li><strong>14</strong> -&#8288; Error in IPC code</li>
+<li><strong>20</strong> -&#8288; Received SIGUSR1 or SIGINT</li>
+<li><strong>21</strong> -&#8288; Some error returned by <strong>waitpid()</strong></li>
+<li><strong>22</strong> -&#8288; Error allocating core memory buffers</li>
+<li><strong>23</strong> -&#8288; Partial transfer due to error</li>
+<li><strong>24</strong> -&#8288; Partial transfer due to vanished source files</li>
+<li><strong>25</strong> -&#8288; The -&#8288;-&#8288;max-delete limit stopped deletions</li>
+<li><strong>30</strong> -&#8288; Timeout in data send/receive</li>
+<li><strong>35</strong> -&#8288; Timeout waiting for daemon connection</li>
+</ul>
+<h2 id="ENVIRONMENT_VARIABLES">ENVIRONMENT VARIABLES<a href="#ENVIRONMENT_VARIABLES" class="tgt"></a></h2>
+<dl>
+
+<dt id="CVSIGNORE"><code>CVSIGNORE</code><a href="#CVSIGNORE" class="tgt"></a></dt><dd>
+<p>The CVSIGNORE environment variable supplements any ignore patterns in
+.cvsignore files. See the <a href="#opt--cvs-exclude"><code>--cvs-exclude</code></a> option for more details.</p>
+</dd>
+
+<dt id="RSYNC_ICONV"><code>RSYNC_ICONV</code><a href="#RSYNC_ICONV" class="tgt"></a></dt><dd>
+<p>Specify a default <a href="#opt--iconv"><code>--iconv</code></a> setting using this environment
+variable. First supported in 3.0.0.</p>
+</dd>
+
+<dt id="RSYNC_OLD_ARGS"><code>RSYNC_OLD_ARGS</code><a href="#RSYNC_OLD_ARGS" class="tgt"></a></dt><dd>
+<p>Specify a &quot;1&quot; if you want the <a href="#opt--old-args"><code>--old-args</code></a> option to be enabled by
+default, a &quot;2&quot; (or more) if you want it to be enabled in the
+repeated-option state, or a &quot;0&quot; to make sure that it is disabled by
+default. When this environment variable is set to a non-zero value, it
+supersedes the <a href="#RSYNC_PROTECT_ARGS"><code>RSYNC_PROTECT_ARGS</code></a> variable.</p>
+<p>This variable is ignored if <a href="#opt--old-args"><code>--old-args</code></a>, <code>--no-old-args</code>, or
+<a href="#opt--secluded-args"><code>--secluded-args</code></a> is specified on the command line.</p>
+<p>First supported in 3.2.4.</p>
+</dd>
+
+<dt id="RSYNC_PROTECT_ARGS"><code>RSYNC_PROTECT_ARGS</code><a href="#RSYNC_PROTECT_ARGS" class="tgt"></a></dt><dd>
+<p>Specify a non-zero numeric value if you want the <a href="#opt--secluded-args"><code>--secluded-args</code></a>
+option to be enabled by default, or a zero value to make sure that it is
+disabled by default.</p>
+<p>This variable is ignored if <a href="#opt--secluded-args"><code>--secluded-args</code></a>, <code>--no-secluded-args</code>,
+or <a href="#opt--old-args"><code>--old-args</code></a> is specified on the command line.</p>
+<p>First supported in 3.1.0. Starting in 3.2.4, this variable is ignored if
+<a href="#RSYNC_OLD_ARGS"><code>RSYNC_OLD_ARGS</code></a> is set to a non-zero value.</p>
+</dd>
+
+<dt id="RSYNC_RSH"><code>RSYNC_RSH</code><a href="#RSYNC_RSH" class="tgt"></a></dt><dd>
+<p>This 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 <a href="#opt--rsh"><code>--rsh</code></a> (<code>-e</code>) option.</p>
+</dd>
+
+<dt id="RSYNC_PROXY"><code>RSYNC_PROXY</code><a href="#RSYNC_PROXY" class="tgt"></a></dt><dd>
+<p>This environment variable allows you to redirect your rsync
+client to use a web proxy when connecting to an rsync daemon. You should
+set <code>RSYNC_PROXY</code> to a hostname:port pair.</p>
+</dd>
+
+<dt id="RSYNC_PASSWORD"><code>RSYNC_PASSWORD</code><a href="#RSYNC_PASSWORD" class="tgt"></a></dt><dd>
+<p>This environment variable allows you to set the password for an rsync
+<strong>daemon</strong> connection, which avoids the password prompt. Note that this
+does <strong>not</strong> supply a password to a remote shell transport such as ssh
+(consult its documentation for how to do that).</p>
+</dd>
+
+<span id="LOGNAME"></span><dt id="USER"><code>USER</code> or <code>LOGNAME</code><a href="#USER" class="tgt"></a></dt><dd>
+<p>The USER or LOGNAME environment variables are used to determine the default
+username sent to an rsync daemon. If neither is set, the username defaults
+to &quot;nobody&quot;. If both are set, <code>USER</code> takes precedence.</p>
+</dd>
+
+<dt id="RSYNC_PARTIAL_DIR"><code>RSYNC_PARTIAL_DIR</code><a href="#RSYNC_PARTIAL_DIR" class="tgt"></a></dt><dd>
+<p>This environment variable specifies the directory to use for a
+<a href="#opt--partial"><code>--partial</code></a> transfer without implying that partial transfers be
+enabled. See the <a href="#opt--partial-dir"><code>--partial-dir</code></a> option for full details.</p>
+</dd>
+
+<dt id="RSYNC_COMPRESS_LIST"><code>RSYNC_COMPRESS_LIST</code><a href="#RSYNC_COMPRESS_LIST" class="tgt"></a></dt><dd>
+<p>This environment variable allows you to customize the negotiation of the
+compression algorithm by specifying an alternate order or a reduced list of
+names. Use the command <code>rsync --version</code> to see the available compression
+names. See the <a href="#opt--compress"><code>--compress</code></a> option for full details.</p>
+</dd>
+
+<dt id="RSYNC_CHECKSUM_LIST"><code>RSYNC_CHECKSUM_LIST</code><a href="#RSYNC_CHECKSUM_LIST" class="tgt"></a></dt><dd>
+<p>This environment variable allows you to customize the negotiation of the
+checksum algorithm by specifying an alternate order or a reduced list of
+names. Use the command <code>rsync --version</code> to see the available checksum
+names. See the <a href="#opt--checksum-choice"><code>--checksum-choice</code></a> option for full details.</p>
+</dd>
+
+<dt id="RSYNC_MAX_ALLOC"><code>RSYNC_MAX_ALLOC</code><a href="#RSYNC_MAX_ALLOC" class="tgt"></a></dt><dd>
+<p>This environment variable sets an allocation maximum as if you had used the
+<a href="#opt--max-alloc"><code>--max-alloc</code></a> option.</p>
+</dd>
+
+<dt id="RSYNC_PORT"><code>RSYNC_PORT</code><a href="#RSYNC_PORT" class="tgt"></a></dt><dd>
+<p>This environment variable is not read by rsync, but is instead set in
+its sub-environment when rsync is running the remote shell in combination
+with a daemon connection. This allows a script such as
+<a href="rsync-ssl.1"><code>rsync-ssl</code></a> to be able to know the port number that the user
+specified on the command line.</p>
+</dd>
+
+<dt id="HOME"><code>HOME</code><a href="#HOME" class="tgt"></a></dt><dd>
+<p>This environment variable is used to find the user's default .cvsignore
+file.</p>
+</dd>
+
+<dt id="RSYNC_CONNECT_PROG"><code>RSYNC_CONNECT_PROG</code><a href="#RSYNC_CONNECT_PROG" class="tgt"></a></dt><dd>
+<p>This environment variable is mainly used in debug setups to set the program
+to use when making a daemon connection. See <a href="#CONNECTING_TO_AN_RSYNC_DAEMON">CONNECTING TO AN RSYNC
+DAEMON</a> for full details.</p>
+</dd>
+
+<dt id="RSYNC_SHELL"><code>RSYNC_SHELL</code><a href="#RSYNC_SHELL" class="tgt"></a></dt><dd>
+<p>This environment variable is mainly used in debug setups to set the program
+to use to run the program specified by <a href="#RSYNC_CONNECT_PROG"><code>RSYNC_CONNECT_PROG</code></a>. See
+<a href="#CONNECTING_TO_AN_RSYNC_DAEMON">CONNECTING TO AN RSYNC DAEMON</a> for full details.</p>
+</dd>
+</dl>
+<h2 id="FILES">FILES<a href="#FILES" class="tgt"></a></h2>
+<p>/etc/rsyncd.conf or rsyncd.conf</p>
+<h2 id="SEE_ALSO">SEE ALSO<a href="#SEE_ALSO" class="tgt"></a></h2>
+<p><a href="rsync-ssl.1"><strong>rsync-ssl</strong>(1)</a>, <a href="rsyncd.conf.5"><strong>rsyncd.conf</strong>(5)</a>, <a href="rrsync.1"><strong>rrsync</strong>(1)</a></p>
+<h2 id="BUGS">BUGS<a href="#BUGS" class="tgt"></a></h2>
+<ul>
+<li>Times are transferred as *nix time_t values.</li>
+<li>When transferring to FAT filesystems rsync may re-sync unmodified files. See
+the comments on the <a href="#opt--modify-window"><code>--modify-window</code></a> option.</li>
+<li>File permissions, devices, etc. are transferred as native numerical values.</li>
+<li>See also the comments on the <a href="#opt--delete"><code>--delete</code></a> option.</li>
+</ul>
+<p>Please report bugs! See the web site at <a href="https://rsync.samba.org/">https://rsync.samba.org/</a>.</p>
+<h2 id="VERSION">VERSION<a href="#VERSION" class="tgt"></a></h2>
+<p>This manpage is current for version 3.2.7 of rsync.</p>
+<h2 id="INTERNAL_OPTIONS">INTERNAL OPTIONS<a href="#INTERNAL_OPTIONS" class="tgt"></a></h2>
+<p>The options <code>--server</code> and <code>--sender</code> are used internally by rsync, and should
+never be typed by a user under normal circumstances. Some awareness of these
+options may be needed in certain scenarios, such as when setting up a login
+that can only run an rsync command. For instance, the support directory of the
+rsync distribution has an example script named rrsync (for restricted rsync)
+that can be used with a restricted ssh login.</p>
+<h2 id="CREDITS">CREDITS<a href="#CREDITS" class="tgt"></a></h2>
+<p>Rsync is distributed under the GNU General Public License. See the file
+<a href="COPYING">COPYING</a> for details.</p>
+<p>An rsync web site is available at <a href="https://rsync.samba.org/">https://rsync.samba.org/</a>. The site
+includes an FAQ-O-Matic which may cover questions unanswered by this manual
+page.</p>
+<p>The rsync github project is <a href="https://github.com/WayneD/rsync">https://github.com/WayneD/rsync</a>.</p>
+<p>We would be delighted to hear from you if you like this program. Please
+contact the mailing-list at <a href="mailto:rsync@lists.samba.org">rsync@lists.samba.org</a>.</p>
+<p>This program uses the excellent zlib compression library written by Jean-loup
+Gailly and Mark Adler.</p>
+<h2 id="THANKS">THANKS<a href="#THANKS" class="tgt"></a></h2>
+<p>Special thanks go out to: John Van Essen, Matt McCutchen, Wesley W. Terpstra,
+David Dykstra, Jos Backus, Sebastian Krahmer, Martin Pool, and our
+gone-but-not-forgotten compadre, J.W. Schultz.</p>
+<p>Thanks also to Richard Brent, Brendan Mackay, Bill Waite, Stephen Rothwell and
+David Bell. I've probably missed some people, my apologies if I have.</p>
+<h2 id="AUTHOR">AUTHOR<a href="#AUTHOR" class="tgt"></a></h2>
+<p>Rsync was originally written by Andrew Tridgell and Paul Mackerras. Many
+people have later contributed to it. It is currently maintained by Wayne
+Davison.</p>
+<p>Mailing lists for support and development are available at
+<a href="https://lists.samba.org/">https://lists.samba.org/</a>.</p>
+<div style="float: right"><p><i>20 Oct 2022</i></p></div>
+</body></html>
diff --git a/rsync.1.md b/rsync.1.md
new file mode 100644
index 0000000..ee0a4f3
--- /dev/null
+++ b/rsync.1.md
@@ -0,0 +1,4842 @@
+## NAME
+
+rsync - a fast, versatile, remote (and local) file-copying tool
+
+## SYNOPSIS
+
+```
+Local:
+ rsync [OPTION...] SRC... [DEST]
+
+Access via remote shell:
+ Pull:
+ rsync [OPTION...] [USER@]HOST:SRC... [DEST]
+ Push:
+ rsync [OPTION...] SRC... [USER@]HOST:DEST
+
+Access via rsync daemon:
+ Pull:
+ rsync [OPTION...] [USER@]HOST::SRC... [DEST]
+ rsync [OPTION...] rsync://[USER@]HOST[:PORT]/SRC... [DEST]
+ Push:
+ rsync [OPTION...] SRC... [USER@]HOST::DEST
+ rsync [OPTION...] SRC... rsync://[USER@]HOST[:PORT]/DEST)
+```
+
+Usages with just one SRC arg and no DEST arg will list the source files instead
+of copying.
+
+The online version of this manpage (that includes cross-linking of topics)
+is available at <https://download.samba.org/pub/rsync/rsync.1>.
+
+## DESCRIPTION
+
+Rsync is a fast and extraordinarily versatile file copying tool. It can copy
+locally, to/from another host over any remote shell, or to/from a remote rsync
+daemon. It offers a large number of options that control every aspect of its
+behavior and permit very flexible specification of the set of files to be
+copied. It is famous for its delta-transfer algorithm, which reduces the
+amount of data sent over the network by sending only the differences between
+the source files and the existing files in the destination. Rsync is widely
+used for backups and mirroring and as an improved copy command for everyday
+use.
+
+Rsync finds files that need to be transferred using a "quick check" algorithm
+(by default) that looks for files that have changed in size or in last-modified
+time. Any changes in the other preserved attributes (as requested by options)
+are made on the destination file directly when the quick check indicates that
+the file's data does not need to be updated.
+
+Some of the additional features of rsync are:
+
+- support for copying links, devices, owners, groups, and permissions
+- exclude and exclude-from options similar to GNU tar
+- a CVS exclude mode for ignoring the same files that CVS would ignore
+- can use any transparent remote shell, including ssh or rsh
+- does not require super-user privileges
+- pipelining of file transfers to minimize latency costs
+- support for anonymous or authenticated rsync daemons (ideal for mirroring)
+
+## GENERAL
+
+Rsync copies files either to or from a remote host, or locally on the current
+host (it does not support copying files between two remote hosts).
+
+There are two different ways for rsync to contact a remote system: using a
+remote-shell program as the transport (such as ssh or rsh) or contacting an
+rsync daemon directly via TCP. The remote-shell transport is used whenever the
+source or destination path contains a single colon (:) separator after a host
+specification. Contacting an rsync daemon directly happens when the source or
+destination path contains a double colon (::) separator after a host
+specification, OR when an rsync:// URL is specified (see also the [USING
+RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTION](#) section for an
+exception to this latter rule).
+
+As a special case, if a single source arg is specified without a destination,
+the files are listed in an output format similar to "`ls -l`".
+
+As expected, if neither the source or destination path specify a remote host,
+the copy occurs locally (see also the [`--list-only`](#opt) option).
+
+Rsync refers to the local side as the client and the remote side as the server.
+Don't confuse server with an rsync daemon. A daemon is always a server, but a
+server can be either a daemon or a remote-shell spawned process.
+
+## SETUP
+
+See the file README.md for installation instructions.
+
+Once installed, you can use rsync to any machine that you can access via a
+remote shell (as well as some that you can access using the rsync daemon-mode
+protocol). For remote transfers, a modern rsync uses ssh for its
+communications, but it may have been configured to use a different remote shell
+by default, such as rsh or remsh.
+
+You can also specify any remote shell you like, either by using the [`-e`](#opt)
+command line option, or by setting the [`RSYNC_RSH`](#) environment variable.
+
+Note that rsync must be installed on both the source and destination machines.
+
+## USAGE
+
+You use rsync in the same way you use rcp. You must specify a source and a
+destination, one of which may be remote.
+
+Perhaps the best way to explain the syntax is with some examples:
+
+> rsync -t *.c foo:src/
+
+This would transfer all files matching the pattern `*.c` from the current
+directory to the directory src on the machine foo. If any of the files already
+exist on the remote system then the rsync remote-update protocol is used to
+update the file by sending only the differences in the data. Note that the
+expansion of wildcards on the command-line (`*.c`) into a list of files is
+handled by the shell before it runs rsync and not by rsync itself (exactly the
+same as all other Posix-style programs).
+
+> rsync -avz foo:src/bar /data/tmp
+
+This would recursively transfer all files from the directory src/bar on the
+machine foo into the /data/tmp/bar directory on the local machine. The files
+are transferred in archive mode, which ensures that symbolic links, devices,
+attributes, permissions, ownerships, etc. are preserved in the transfer.
+Additionally, compression will be used to reduce the size of data portions of
+the transfer.
+
+> rsync -avz foo:src/bar/ /data/tmp
+
+A trailing slash on the source changes this behavior to avoid creating an
+additional directory level at the destination. You can think of a trailing /
+on a source as meaning "copy the contents of this directory" as opposed to
+"copy the directory by name", but in both cases the attributes of the
+containing directory are transferred to the containing directory on the
+destination. In other words, each of the following commands copies the files
+in the same way, including their setting of the attributes of /dest/foo:
+
+> rsync -av /src/foo /dest
+> rsync -av /src/foo/ /dest/foo
+
+Note also that host and module references don't require a trailing slash to
+copy the contents of the default directory. For example, both of these copy
+the remote directory's contents into "/dest":
+
+> rsync -av host: /dest
+> rsync -av host::module /dest
+
+You can also use rsync in local-only mode, where both the source and
+destination don't have a ':' in the name. In this case it behaves like an
+improved copy command.
+
+Finally, you can list all the (listable) modules available from a particular
+rsync daemon by leaving off the module name:
+
+> rsync somehost.mydomain.com::
+
+## COPYING TO A DIFFERENT NAME
+
+When you want to copy a directory to a different name, use a trailing slash on
+the source directory to put the contents of the directory into any destination
+directory you like:
+
+> rsync -ai foo/ bar/
+
+Rsync also has the ability to customize a destination file's name when copying
+a single item. The rules for this are:
+
+- The transfer list must consist of a single item (either a file or an empty
+ directory)
+- The final element of the destination path must not exist as a directory
+- The destination path must not have been specified with a trailing slash
+
+Under those circumstances, rsync will set the name of the destination's single
+item to the last element of the destination path. Keep in mind that it is best
+to only use this idiom when copying a file and use the above trailing-slash
+idiom when copying a directory.
+
+The following example copies the `foo.c` file as `bar.c` in the `save` dir
+(assuming that `bar.c` isn't a directory):
+
+> rsync -ai src/foo.c save/bar.c
+
+The single-item copy rule might accidentally bite you if you unknowingly copy a
+single item and specify a destination dir that doesn't exist (without using a
+trailing slash). For example, if `src/*.c` matches one file and `save/dir`
+doesn't exist, this will confuse you by naming the destination file `save/dir`:
+
+> rsync -ai src/*.c save/dir
+
+To prevent such an accident, either make sure the destination dir exists or
+specify the destination path with a trailing slash:
+
+> rsync -ai src/*.c save/dir/
+
+## SORTED TRANSFER ORDER
+
+Rsync always sorts the specified filenames into its internal transfer list.
+This handles the merging together of the contents of identically named
+directories, makes it easy to remove duplicate filenames. It can, however,
+confuse someone when the files are transferred in a different order than what
+was given on the command-line.
+
+If you need a particular file to be transferred prior to another, either
+separate the files into different rsync calls, or consider using
+[`--delay-updates`](#opt) (which doesn't affect the sorted transfer order, but
+does make the final file-updating phase happen much more rapidly).
+
+## MULTI-HOST SECURITY
+
+Rsync takes steps to ensure that the file requests that are shared in a
+transfer are protected against various security issues. Most of the potential
+problems arise on the receiving side where rsync takes steps to ensure that the
+list of files being transferred remains within the bounds of what was
+requested.
+
+Toward this end, rsync 3.1.2 and later have aborted when a file list contains
+an absolute or relative path that tries to escape out of the top of the
+transfer. Also, beginning with version 3.2.5, rsync does two more safety
+checks of the file list to (1) ensure that no extra source arguments were added
+into the transfer other than those that the client requested and (2) ensure
+that the file list obeys the exclude rules that were sent to the sender.
+
+For those that don't yet have a 3.2.5 client rsync (or those that want to be
+extra careful), it is safest to do a copy into a dedicated destination
+directory for the remote files when you don't trust the remote host. For
+example, instead of doing an rsync copy into your home directory:
+
+> rsync -aiv host1:dir1 ~
+
+Dedicate a "host1-files" dir to the remote content:
+
+> rsync -aiv host1:dir1 ~/host1-files
+
+See the [`--trust-sender`](#opt) option for additional details.
+
+CAUTION: it is not particularly safe to use rsync to copy files from a
+case-preserving filesystem to a case-ignoring filesystem. If you must perform
+such a copy, you should either disable symlinks via `--no-links` or enable the
+munging of symlinks via [`--munge-links`](#opt) (and make sure you use the
+right local or remote option). This will prevent rsync from doing potentially
+dangerous things if a symlink name overlaps with a file or directory. It does
+not, however, ensure that you get a full copy of all the files (since that may
+not be possible when the names overlap). A potentially better solution is to
+list all the source files and create a safe list of filenames that you pass to
+the [`--files-from`](#opt) option. Any files that conflict in name would need
+to be copied to different destination directories using more than one copy.
+
+While a copy of a case-ignoring filesystem to a case-ignoring filesystem can
+work out fairly well, if no `--delete-during` or `--delete-before` option is
+active, rsync can potentially update an existing file on the receiveing side
+without noticing that the upper-/lower-case of the filename should be changed
+to match the sender.
+
+## ADVANCED USAGE
+
+The syntax for requesting multiple files from a remote host is done by
+specifying additional remote-host args in the same style as the first, or with
+the hostname omitted. For instance, all these work:
+
+> rsync -aiv host:file1 :file2 host:file{3,4} /dest/
+> rsync -aiv host::modname/file{1,2} host::modname/extra /dest/
+> rsync -aiv host::modname/first ::extra-file{1,2} /dest/
+
+Note that a daemon connection only supports accessing one module per copy
+command, so if the start of a follow-up path doesn't begin with the
+modname of the first path, it is assumed to be a path in the module (such as
+the extra-file1 & extra-file2 that are grabbed above).
+
+Really old versions of rsync (2.6.9 and before) only allowed specifying one
+remote-source arg, so some people have instead relied on the remote-shell
+performing space splitting to break up an arg into multiple paths. Such
+unintuitive behavior is no longer supported by default (though you can request
+it, as described below).
+
+Starting in 3.2.4, filenames are passed to a remote shell in such a way as to
+preserve the characters you give it. Thus, if you ask for a file with spaces
+in the name, that's what the remote rsync looks for:
+
+> rsync -aiv host:'a simple file.pdf' /dest/
+
+If you use scripts that have been written to manually apply extra quoting to
+the remote rsync args (or to require remote arg splitting), you can ask rsync
+to let your script handle the extra escaping. This is done by either adding
+the [`--old-args`](#opt) option to the rsync runs in the script (which requires
+a new rsync) or exporting [RSYNC_OLD_ARGS](#)=1 and [RSYNC_PROTECT_ARGS](#)=0
+(which works with old or new rsync versions).
+
+## CONNECTING TO AN RSYNC DAEMON
+
+It is also possible to use rsync without a remote shell as the transport. In
+this case you will directly connect to a remote rsync daemon, typically using
+TCP port 873. (This obviously requires the daemon to be running on the remote
+system, so refer to the [STARTING AN RSYNC DAEMON TO ACCEPT CONNECTIONS](#)
+section below for information on that.)
+
+Using rsync in this way is the same as using it with a remote shell except
+that:
+
+- Use either double-colon syntax or rsync:// URL syntax instead of the
+ single-colon (remote shell) syntax.
+- The first element of the "path" is actually a module name.
+- Additional remote source args can use an abbreviated syntax that omits the
+ hostname and/or the module name, as discussed in [ADVANCED USAGE](#).
+- The remote daemon may print a "message of the day" when you connect.
+- If you specify only the host (with no module or path) then a list of
+ accessible modules on the daemon is output.
+- If you specify a remote source path but no destination, a listing of the
+ matching files on the remote daemon is output.
+- The [`--rsh`](#opt) (`-e`) option must be omitted to avoid changing the
+ connection style from using a socket connection to [USING RSYNC-DAEMON
+ FEATURES VIA A REMOTE-SHELL CONNECTION](#).
+
+An example that copies all the files in a remote module named "src":
+
+> rsync -av host::src /dest
+
+Some modules on the remote daemon may require authentication. If so, you will
+receive a password prompt when you connect. You can avoid the password prompt
+by setting the environment variable [`RSYNC_PASSWORD`](#) to the password you
+want to use or using the [`--password-file`](#opt) option. This may be useful
+when scripting rsync.
+
+WARNING: On some systems environment variables are visible to all users. On
+those systems using [`--password-file`](#opt) is recommended.
+
+You may establish the connection via a web proxy by setting the environment
+variable [`RSYNC_PROXY`](#) to a hostname:port pair pointing to your web proxy.
+Note that your web proxy's configuration must support proxy connections to port
+873.
+
+You may also establish a daemon connection using a program as a proxy by
+setting the environment variable [`RSYNC_CONNECT_PROG`](#) to the commands you
+wish to run in place of making a direct socket connection. The string may
+contain the escape "%H" to represent the hostname specified in the rsync
+command (so use "%%" if you need a single "%" in your string). For example:
+
+> export RSYNC_CONNECT_PROG='ssh proxyhost nc %H 873'
+> rsync -av targethost1::module/src/ /dest/
+> rsync -av rsync://targethost2/module/src/ /dest/
+
+The command specified above uses ssh to run nc (netcat) on a proxyhost, which
+forwards all data to port 873 (the rsync daemon) on the targethost (%H).
+
+Note also that if the [`RSYNC_SHELL`](#) environment variable is set, that
+program will be used to run the `RSYNC_CONNECT_PROG` command instead of using
+the default shell of the **system()** call.
+
+## USING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTION
+
+It is sometimes useful to use various features of an rsync daemon (such as
+named modules) without actually allowing any new socket connections into a
+system (other than what is already required to allow remote-shell access).
+Rsync supports connecting to a host using a remote shell and then spawning a
+single-use "daemon" server that expects to read its config file in the home dir
+of the remote user. This can be useful if you want to encrypt a daemon-style
+transfer's data, but since the daemon is started up fresh by the remote user,
+you may not be able to use features such as chroot or change the uid used by
+the daemon. (For another way to encrypt a daemon transfer, consider using ssh
+to tunnel a local port to a remote machine and configure a normal rsync daemon
+on that remote host to only allow connections from "localhost".)
+
+From the user's perspective, a daemon transfer via a remote-shell connection
+uses nearly the same command-line syntax as a normal rsync-daemon transfer,
+with the only exception being that you must explicitly set the remote shell
+program on the command-line with the [`--rsh=COMMAND`](#opt) option. (Setting the
+RSYNC_RSH in the environment will not turn on this functionality.) For example:
+
+> rsync -av --rsh=ssh host::module /dest
+
+If you need to specify a different remote-shell user, keep in mind that the
+user@ prefix in front of the host is specifying the rsync-user value (for a
+module that requires user-based authentication). This means that you must give
+the '-l user' option to ssh when specifying the remote-shell, as in this
+example that uses the short version of the [`--rsh`](#opt) option:
+
+> rsync -av -e "ssh -l ssh-user" rsync-user@host::module /dest
+
+The "ssh-user" will be used at the ssh level; the "rsync-user" will be used to
+log-in to the "module".
+
+In this setup, the daemon is started by the ssh command that is accessing the
+system (which can be forced via the `~/.ssh/authorized_keys` file, if desired).
+However, when accessing a daemon directly, it needs to be started beforehand.
+
+## STARTING AN RSYNC DAEMON TO ACCEPT CONNECTIONS
+
+In order to connect to an rsync daemon, the remote system needs to have a
+daemon already running (or it needs to have configured something like inetd to
+spawn an rsync daemon for incoming connections on a particular port). For full
+information on how to start a daemon that will handling incoming socket
+connections, see the [**rsyncd.conf**(5)](rsyncd.conf.5) manpage -- that is
+the config file for the daemon, and it contains the full details for how to run
+the daemon (including stand-alone and inetd configurations).
+
+If you're using one of the remote-shell transports for the transfer, there is
+no need to manually start an rsync daemon.
+
+## EXAMPLES
+
+Here are some examples of how rsync can be used.
+
+To backup a home directory, which consists of large MS Word files and mail
+folders, a per-user cron job can be used that runs this each day:
+
+> rsync -aiz . bkhost:backup/joe/
+
+To move some files from a remote host to the local host, you could run:
+
+> rsync -aiv --remove-source-files rhost:/tmp/{file1,file2}.c ~/src/
+
+## OPTION SUMMARY
+
+Here is a short summary of the options available in rsync. Each option also
+has its own detailed description later in this manpage.
+
+[comment]: # (help-rsync.h)
+[comment]: # (Keep these short enough that they'll be under 80 chars when indented by 7 chars.)
+
+```
+--verbose, -v increase verbosity
+--info=FLAGS fine-grained informational verbosity
+--debug=FLAGS fine-grained debug verbosity
+--stderr=e|a|c change stderr output mode (default: errors)
+--quiet, -q suppress non-error messages
+--no-motd suppress daemon-mode MOTD
+--checksum, -c skip based on checksum, not mod-time & size
+--archive, -a archive mode is -rlptgoD (no -A,-X,-U,-N,-H)
+--no-OPTION turn off an implied OPTION (e.g. --no-D)
+--recursive, -r recurse into directories
+--relative, -R use relative path names
+--no-implied-dirs don't send implied dirs with --relative
+--backup, -b make backups (see --suffix & --backup-dir)
+--backup-dir=DIR make backups into hierarchy based in DIR
+--suffix=SUFFIX backup suffix (default ~ w/o --backup-dir)
+--update, -u skip files that are newer on the receiver
+--inplace update destination files in-place
+--append append data onto shorter files
+--append-verify --append w/old data in file checksum
+--dirs, -d transfer directories without recursing
+--old-dirs, --old-d works like --dirs when talking to old rsync
+--mkpath create destination's missing path components
+--links, -l copy symlinks as symlinks
+--copy-links, -L transform symlink into referent file/dir
+--copy-unsafe-links only "unsafe" symlinks are transformed
+--safe-links ignore symlinks that point outside the tree
+--munge-links munge symlinks to make them safe & unusable
+--copy-dirlinks, -k transform symlink to dir into referent dir
+--keep-dirlinks, -K treat symlinked dir on receiver as dir
+--hard-links, -H preserve hard links
+--perms, -p preserve permissions
+--executability, -E preserve executability
+--chmod=CHMOD affect file and/or directory permissions
+--acls, -A preserve ACLs (implies --perms)
+--xattrs, -X preserve extended attributes
+--owner, -o preserve owner (super-user only)
+--group, -g preserve group
+--devices preserve device files (super-user only)
+--copy-devices copy device contents as a regular file
+--write-devices write to devices as files (implies --inplace)
+--specials preserve special files
+-D same as --devices --specials
+--times, -t preserve modification times
+--atimes, -U preserve access (use) times
+--open-noatime avoid changing the atime on opened files
+--crtimes, -N preserve create times (newness)
+--omit-dir-times, -O omit directories from --times
+--omit-link-times, -J omit symlinks from --times
+--super receiver attempts super-user activities
+--fake-super store/recover privileged attrs using xattrs
+--sparse, -S turn sequences of nulls into sparse blocks
+--preallocate allocate dest files before writing them
+--dry-run, -n perform a trial run with no changes made
+--whole-file, -W copy files whole (w/o delta-xfer algorithm)
+--checksum-choice=STR choose the checksum algorithm (aka --cc)
+--one-file-system, -x don't cross filesystem boundaries
+--block-size=SIZE, -B force a fixed checksum block-size
+--rsh=COMMAND, -e specify the remote shell to use
+--rsync-path=PROGRAM specify the rsync to run on remote machine
+--existing skip creating new files on receiver
+--ignore-existing skip updating files that exist on receiver
+--remove-source-files sender removes synchronized files (non-dir)
+--del an alias for --delete-during
+--delete delete extraneous files from dest dirs
+--delete-before receiver deletes before xfer, not during
+--delete-during receiver deletes during the transfer
+--delete-delay find deletions during, delete after
+--delete-after receiver deletes after transfer, not during
+--delete-excluded also delete excluded files from dest dirs
+--ignore-missing-args ignore missing source args without error
+--delete-missing-args delete missing source args from destination
+--ignore-errors delete even if there are I/O errors
+--force force deletion of dirs even if not empty
+--max-delete=NUM don't delete more than NUM files
+--max-size=SIZE don't transfer any file larger than SIZE
+--min-size=SIZE don't transfer any file smaller than SIZE
+--max-alloc=SIZE change a limit relating to memory alloc
+--partial keep partially transferred files
+--partial-dir=DIR put a partially transferred file into DIR
+--delay-updates put all updated files into place at end
+--prune-empty-dirs, -m prune empty directory chains from file-list
+--numeric-ids don't map uid/gid values by user/group name
+--usermap=STRING custom username mapping
+--groupmap=STRING custom groupname mapping
+--chown=USER:GROUP simple username/groupname mapping
+--timeout=SECONDS set I/O timeout in seconds
+--contimeout=SECONDS set daemon connection timeout in seconds
+--ignore-times, -I don't skip files that match size and time
+--size-only skip files that match in size
+--modify-window=NUM, -@ set the accuracy for mod-time comparisons
+--temp-dir=DIR, -T create temporary files in directory DIR
+--fuzzy, -y find similar file for basis if no dest file
+--compare-dest=DIR also compare destination files relative to DIR
+--copy-dest=DIR ... and include copies of unchanged files
+--link-dest=DIR hardlink to files in DIR when unchanged
+--compress, -z compress file data during the transfer
+--compress-choice=STR choose the compression algorithm (aka --zc)
+--compress-level=NUM explicitly set compression level (aka --zl)
+--skip-compress=LIST skip compressing files with suffix in LIST
+--cvs-exclude, -C auto-ignore files in the same way CVS does
+--filter=RULE, -f add a file-filtering RULE
+-F same as --filter='dir-merge /.rsync-filter'
+ repeated: --filter='- .rsync-filter'
+--exclude=PATTERN exclude files matching PATTERN
+--exclude-from=FILE read exclude patterns from FILE
+--include=PATTERN don't exclude files matching PATTERN
+--include-from=FILE read include patterns from FILE
+--files-from=FILE read list of source-file names from FILE
+--from0, -0 all *-from/filter files are delimited by 0s
+--old-args disable the modern arg-protection idiom
+--secluded-args, -s use the protocol to safely send the args
+--trust-sender trust the remote sender's file list
+--copy-as=USER[:GROUP] specify user & optional group for the copy
+--address=ADDRESS bind address for outgoing socket to daemon
+--port=PORT specify double-colon alternate port number
+--sockopts=OPTIONS specify custom TCP options
+--blocking-io use blocking I/O for the remote shell
+--outbuf=N|L|B set out buffering to None, Line, or Block
+--stats give some file-transfer stats
+--8-bit-output, -8 leave high-bit chars unescaped in output
+--human-readable, -h output numbers in a human-readable format
+--progress show progress during transfer
+-P same as --partial --progress
+--itemize-changes, -i output a change-summary for all updates
+--remote-option=OPT, -M send OPTION to the remote side only
+--out-format=FORMAT output updates using the specified FORMAT
+--log-file=FILE log what we're doing to the specified FILE
+--log-file-format=FMT log updates using the specified FMT
+--password-file=FILE read daemon-access password from FILE
+--early-input=FILE use FILE for daemon's early exec input
+--list-only list the files instead of copying them
+--bwlimit=RATE limit socket I/O bandwidth
+--stop-after=MINS Stop rsync after MINS minutes have elapsed
+--stop-at=y-m-dTh:m Stop rsync at the specified point in time
+--fsync fsync every written file
+--write-batch=FILE write a batched update to FILE
+--only-write-batch=FILE like --write-batch but w/o updating dest
+--read-batch=FILE read a batched update from FILE
+--protocol=NUM force an older protocol version to be used
+--iconv=CONVERT_SPEC request charset conversion of filenames
+--checksum-seed=NUM set block/file checksum seed (advanced)
+--ipv4, -4 prefer IPv4
+--ipv6, -6 prefer IPv6
+--version, -V print the version + other info and exit
+--help, -h (*) show this help (* -h is help only on its own)
+```
+
+Rsync can also be run as a daemon, in which case the following options are
+accepted:
+
+[comment]: # (help-rsyncd.h)
+
+```
+--daemon run as an rsync daemon
+--address=ADDRESS bind to the specified address
+--bwlimit=RATE limit socket I/O bandwidth
+--config=FILE specify alternate rsyncd.conf file
+--dparam=OVERRIDE, -M override global daemon config parameter
+--no-detach do not detach from the parent
+--port=PORT listen on alternate port number
+--log-file=FILE override the "log file" setting
+--log-file-format=FMT override the "log format" setting
+--sockopts=OPTIONS specify custom TCP options
+--verbose, -v increase verbosity
+--ipv4, -4 prefer IPv4
+--ipv6, -6 prefer IPv6
+--help, -h show this help (when used with --daemon)
+```
+
+## OPTIONS
+
+Rsync accepts both long (double-dash + word) and short (single-dash + letter)
+options. The full list of the available options are described below. If an
+option can be specified in more than one way, the choices are comma-separated.
+Some options only have a long variant, not a short.
+
+If the option takes a parameter, the parameter is only listed after the long
+variant, even though it must also be specified for the short. When specifying
+a parameter, you can either use the form `--option=param`, `--option param`,
+`-o=param`, `-o param`, or `-oparam` (the latter choices assume that your
+option has a short variant).
+
+The parameter may need to be quoted in some manner for it to survive the
+shell's command-line parsing. Also keep in mind that a leading tilde (`~`) in
+a pathname is substituted by your shell, so make sure that you separate the
+option name from the pathname using a space if you want the local shell to
+expand it.
+
+[comment]: # (Some markup below uses a literal non-breakable space when a backtick string)
+[comment]: # (needs to contain a space since markdown strips spaces from the start/end)
+
+[comment]: # (An OL starting at 0 is converted into a DL by the parser.)
+
+0. `--help`
+
+ Print a short help page describing the options available in rsync and exit.
+ You can also use `-h` for `--help` when it is used without any other
+ options (since it normally means [`--human-readable`](#opt)).
+
+0. `--version`, `-V`
+
+ Print the rsync version plus other info and exit. When repeated, the
+ information is output is a JSON format that is still fairly readable
+ (client side only).
+
+ The output includes a list of compiled-in capabilities, a list of
+ optimizations, the default list of checksum algorithms, the default list of
+ compression algorithms, the default list of daemon auth digests, a link to
+ the rsync web site, and a few other items.
+
+0. `--verbose`, `-v`
+
+ This option increases the amount of information you are given during the
+ transfer. By default, rsync works silently. A single `-v` will give you
+ information about what files are being transferred and a brief summary at
+ the end. Two `-v` options will give you information on what files are
+ being skipped and slightly more information at the end. More than two `-v`
+ options should only be used if you are debugging rsync.
+
+ The end-of-run summary tells you the number of bytes sent to the remote
+ rsync (which is the receiving side on a local copy), the number of bytes
+ received from the remote host, and the average bytes per second of the
+ transferred data computed over the entire length of the rsync run. The
+ second line shows the total size (in bytes), which is the sum of all the
+ file sizes that rsync considered transferring. It also shows a "speedup"
+ value, which is a ratio of the total file size divided by the sum of the
+ sent and received bytes (which is really just a feel-good bigger-is-better
+ number). Note that these byte values can be made more (or less)
+ human-readable by using the [`--human-readable`](#opt) (or
+ `--no-human-readable`) options.
+
+ In a modern rsync, the `-v` option is equivalent to the setting of groups
+ of [`--info`](#opt) and [`--debug`](#opt) options. You can choose to use
+ these newer options in addition to, or in place of using `--verbose`, as
+ any fine-grained settings override the implied settings of `-v`. Both
+ [`--info`](#opt) and [`--debug`](#opt) have a way to ask for help that
+ tells you exactly what flags are set for each increase in verbosity.
+
+ However, do keep in mind that a daemon's "`max verbosity`" setting will limit
+ how high of a level the various individual flags can be set on the daemon
+ side. For instance, if the max is 2, then any info and/or debug flag that
+ is set to a higher value than what would be set by `-vv` will be downgraded
+ to the `-vv` level in the daemon's logging.
+
+0. `--info=FLAGS`
+
+ This option lets you have fine-grained control over the information output
+ you want to see. An individual flag name may be followed by a level
+ number, with 0 meaning to silence that output, 1 being the default output
+ level, and higher numbers increasing the output of that flag (for those
+ that support higher levels). Use `--info=help` to see all the available
+ flag names, what they output, and what flag names are added for each
+ increase in the verbose level. Some examples:
+
+ > rsync -a --info=progress2 src/ dest/
+ > rsync -avv --info=stats2,misc1,flist0 src/ dest/
+
+ Note that `--info=name`'s output is affected by the [`--out-format`](#opt)
+ and [`--itemize-changes`](#opt) (`-i`) options. See those options for more
+ information on what is output and when.
+
+ This option was added to 3.1.0, so an older rsync on the server side might
+ reject your attempts at fine-grained control (if one or more flags needed
+ to be send to the server and the server was too old to understand them).
+ See also the "`max verbosity`" caveat above when dealing with a daemon.
+
+0. `--debug=FLAGS`
+
+ This option lets you have fine-grained control over the debug output you
+ want to see. An individual flag name may be followed by a level number,
+ with 0 meaning to silence that output, 1 being the default output level,
+ and higher numbers increasing the output of that flag (for those that
+ support higher levels). Use `--debug=help` to see all the available flag
+ names, what they output, and what flag names are added for each increase in
+ the verbose level. Some examples:
+
+ > rsync -avvv --debug=none src/ dest/
+ > rsync -avA --del --debug=del2,acl src/ dest/
+
+ Note that some debug messages will only be output when the [`--stderr=all`](#opt)
+ option is specified, especially those pertaining to I/O and buffer debugging.
+
+ Beginning in 3.2.0, this option is no longer auto-forwarded to the server
+ side in order to allow you to specify different debug values for each side
+ of the transfer, as well as to specify a new debug option that is only
+ present in one of the rsync versions. If you want to duplicate the same
+ option on both sides, using brace expansion is an easy way to save you some
+ typing. This works in zsh and bash:
+
+ > rsync -aiv {-M,}--debug=del2 src/ dest/
+
+0. `--stderr=errors|all|client`
+
+ This option controls which processes output to stderr and if info messages
+ are also changed to stderr. The mode strings can be abbreviated, so feel
+ free to use a single letter value. The 3 possible choices are:
+
+ - `errors` - (the default) causes all the rsync processes to send an
+ error directly to stderr, even if the process is on the remote side of
+ the transfer. Info messages are sent to the client side via the protocol
+ stream. If stderr is not available (i.e. when directly connecting with a
+ daemon via a socket) errors fall back to being sent via the protocol
+ stream.
+
+ - `all` - causes all rsync messages (info and error) to get written
+ directly to stderr from all (possible) processes. This causes stderr to
+ become line-buffered (instead of raw) and eliminates the ability to
+ divide up the info and error messages by file handle. For those doing
+ debugging or using several levels of verbosity, this option can help to
+ avoid clogging up the transfer stream (which should prevent any chance of
+ a deadlock bug hanging things up). It also allows [`--debug`](#opt) to
+ enable some extra I/O related messages.
+
+ - `client` - causes all rsync messages to be sent to the client side
+ via the protocol stream. One client process outputs all messages, with
+ errors on stderr and info messages on stdout. This **was** the default
+ in older rsync versions, but can cause error delays when a lot of
+ transfer data is ahead of the messages. If you're pushing files to an
+ older rsync, you may want to use `--stderr=all` since that idiom has
+ been around for several releases.
+
+ This option was added in rsync 3.2.3. This version also began the
+ forwarding of a non-default setting to the remote side, though rsync uses
+ the backward-compatible options `--msgs2stderr` and `--no-msgs2stderr` to
+ represent the `all` and `client` settings, respectively. A newer rsync
+ will continue to accept these older option names to maintain compatibility.
+
+0. `--quiet`, `-q`
+
+ This option decreases the amount of information you are given during the
+ transfer, notably suppressing information messages from the remote server.
+ This option is useful when invoking rsync from cron.
+
+0. `--no-motd`
+
+ This option affects the information that is output by the client at the
+ start of a daemon transfer. This suppresses the message-of-the-day (MOTD)
+ text, but it also affects the list of modules that the daemon sends in
+ response to the "rsync host::" request (due to a limitation in the rsync
+ protocol), so omit this option if you want to request the list of modules
+ from the daemon.
+
+0. `--ignore-times`, `-I`
+
+ Normally rsync will skip any files that are already the same size and have
+ the same modification timestamp. This option turns off this "quick check"
+ behavior, causing all files to be updated.
+
+ This option can be confusing compared to [`--ignore-existing`](#opt) and
+ [`--ignore-non-existing`](#opt) in that that they cause rsync to transfer
+ fewer files, while this option causes rsync to transfer more files.
+
+0. `--size-only`
+
+ This modifies rsync's "quick check" algorithm for finding files that need
+ to be transferred, changing it from the default of transferring files with
+ either a changed size or a changed last-modified time to just looking for
+ files that have changed in size. This is useful when starting to use rsync
+ after using another mirroring system which may not preserve timestamps
+ exactly.
+
+0. `--modify-window=NUM`, `-@`
+
+ When comparing two timestamps, rsync treats the timestamps as being equal
+ if they differ by no more than the modify-window value. The default is 0,
+ which matches just integer seconds. If you specify a negative value (and
+ the receiver is at least version 3.1.3) then nanoseconds will also be taken
+ into account. Specifying 1 is useful for copies to/from MS Windows FAT
+ filesystems, because FAT represents times with a 2-second resolution
+ (allowing times to differ from the original by up to 1 second).
+
+ If you want all your transfers to default to comparing nanoseconds, you can
+ create a `~/.popt` file and put these lines in it:
+
+ > rsync alias -a -a@-1
+ > rsync alias -t -t@-1
+
+ With that as the default, you'd need to specify `--modify-window=0` (aka
+ `-@0`) to override it and ignore nanoseconds, e.g. if you're copying
+ between ext3 and ext4, or if the receiving rsync is older than 3.1.3.
+
+0. `--checksum`, `-c`
+
+ This changes the way rsync checks if the files have been changed and are in
+ need of a transfer. Without this option, rsync uses a "quick check" that
+ (by default) checks if each file's size and time of last modification match
+ between the sender and receiver. This option changes this to compare a
+ 128-bit checksum for each file that has a matching size. Generating the
+ checksums means that both sides will expend a lot of disk I/O reading all
+ the data in the files in the transfer, so this can slow things down
+ significantly (and this is prior to any reading that will be done to
+ transfer changed files)
+
+ The sending side generates its checksums while it is doing the file-system
+ scan that builds the list of the available files. The receiver generates
+ its checksums when it is scanning for changed files, and will checksum any
+ file that has the same size as the corresponding sender's file: files with
+ either a changed size or a changed checksum are selected for transfer.
+
+ Note that rsync always verifies that each _transferred_ file was correctly
+ reconstructed on the receiving side by checking a whole-file checksum that
+ is generated as the file is transferred, but that automatic
+ after-the-transfer verification has nothing to do with this option's
+ before-the-transfer "Does this file need to be updated?" check.
+
+ The checksum used is auto-negotiated between the client and the server, but
+ can be overridden using either the [`--checksum-choice`](#opt) (`--cc`)
+ option or an environment variable that is discussed in that option's
+ section.
+
+0. `--archive`, `-a`
+
+ This is equivalent to `-rlptgoD`. It is a quick way of saying you want
+ recursion and want to preserve almost everything. Be aware that it does
+ **not** include preserving ACLs (`-A`), xattrs (`-X`), atimes (`-U`),
+ crtimes (`-N`), nor the finding and preserving of hardlinks (`-H`).
+
+ The only exception to the above equivalence is when [`--files-from`](#opt)
+ is specified, in which case [`-r`](#opt) is not implied.
+
+0. `--no-OPTION`
+
+ You may turn off one or more implied options by prefixing the option name
+ with "no-". Not all positive options have a negated opposite, but a lot
+ do, including those that can be used to disable an implied option (e.g.
+ `--no-D`, `--no-perms`) or have different defaults in various circumstances
+ (e.g. [`--no-whole-file`](#opt), `--no-blocking-io`, `--no-dirs`). Every
+ valid negated option accepts both the short and the long option name after
+ the "no-" prefix (e.g. `--no-R` is the same as `--no-relative`).
+
+ As an example, if you want to use [`--archive`](#opt) (`-a`) but don't want
+ [`--owner`](#opt) (`-o`), instead of converting `-a` into `-rlptgD`, you
+ can specify `-a --no-o` (aka `--archive --no-owner`).
+
+ The order of the options is important: if you specify `--no-r -a`, the `-r`
+ option would end up being turned on, the opposite of `-a --no-r`. Note
+ also that the side-effects of the [`--files-from`](#opt) option are NOT
+ positional, as it affects the default state of several options and slightly
+ changes the meaning of [`-a`](#opt) (see the [`--files-from`](#opt) option
+ for more details).
+
+0. `--recursive`, `-r`
+
+ This tells rsync to copy directories recursively. See also
+ [`--dirs`](#opt) (`-d`) for an option that allows the scanning of a single
+ directory.
+
+ See the [`--inc-recursive`](#opt) option for a discussion of the
+ incremental recursion for creating the list of files to transfer.
+
+0. `--inc-recursive`, `--i-r`
+
+ This option explicitly enables on incremental recursion when scanning for
+ files, which is enabled by default when using the [`--recursive`](#opt)
+ option and both sides of the transfer are running rsync 3.0.0 or newer.
+
+ Incremental recursion uses much less memory than non-incremental, while
+ also beginning the transfer more quickly (since it doesn't need to scan the
+ entire transfer hierarchy before it starts transferring files). If no
+ recursion is enabled in the source files, this option has no effect.
+
+ Some options require rsync to know the full file list, so these options
+ disable the incremental recursion mode. These include:
+ - [`--delete-before`](#opt) (the old default of [`--delete`](#opt))
+ - [`--delete-after`](#opt)
+ - [`--prune-empty-dirs`](#opt)
+ - [`--delay-updates`](#opt)
+
+ In order to make [`--delete`](#opt) compatible with incremental recursion,
+ rsync 3.0.0 made [`--delete-during`](#opt) the default delete mode (which
+ was first added in 2.6.4).
+
+ One side-effect of incremental recursion is that any missing
+ sub-directories inside a recursively-scanned directory are (by default)
+ created prior to recursing into the sub-dirs. This earlier creation point
+ (compared to a non-incremental recursion) allows rsync to then set the
+ modify time of the finished directory right away (without having to delay
+ that until a bunch of recursive copying has finished). However, these
+ early directories don't yet have their completed mode, mtime, or ownership
+ set -- they have more restrictive rights until the subdirectory's copying
+ actually begins. This early-creation idiom can be avoided by using the
+ [`--omit-dir-times`](#opt) option.
+
+ Incremental recursion can be disabled using the
+ [`--no-inc-recursive`](#opt) (`--no-i-r`) option.
+
+0. `--no-inc-recursive`, `--no-i-r`
+
+ Disables the new incremental recursion algorithm of the
+ [`--recursive`](#opt) option. This makes rsync scan the full file list
+ before it begins to transfer files. See [`--inc-recursive`](#opt) for more
+ info.
+
+0. `--relative`, `-R`
+
+ Use relative paths. This means that the full path names specified on the
+ command line are sent to the server rather than just the last parts of the
+ filenames. This is particularly useful when you want to send several
+ different directories at the same time. For example, if you used this
+ command:
+
+ > rsync -av /foo/bar/baz.c remote:/tmp/
+
+ would create a file named baz.c in /tmp/ on the remote machine. If instead
+ you used
+
+ > rsync -avR /foo/bar/baz.c remote:/tmp/
+
+ then a file named /tmp/foo/bar/baz.c would be created on the remote
+ machine, preserving its full path. These extra path elements are called
+ "implied directories" (i.e. the "foo" and the "foo/bar" directories in the
+ above example).
+
+ Beginning with rsync 3.0.0, rsync always sends these implied directories as
+ real directories in the file list, even if a path element is really a
+ symlink on the sending side. This prevents some really unexpected behaviors
+ when copying the full path of a file that you didn't realize had a symlink
+ in its path. If you want to duplicate a server-side symlink, include both
+ the symlink via its path, and referent directory via its real path. If
+ you're dealing with an older rsync on the sending side, you may need to use
+ the [`--no-implied-dirs`](#opt) option.
+
+ It is also possible to limit the amount of path information that is sent as
+ implied directories for each path you specify. With a modern rsync on the
+ sending side (beginning with 2.6.7), you can insert a dot and a slash into
+ the source path, like this:
+
+ > rsync -avR /foo/./bar/baz.c remote:/tmp/
+
+ That would create /tmp/bar/baz.c on the remote machine. (Note that the dot
+ must be followed by a slash, so "/foo/." would not be abbreviated.) For
+ older rsync versions, you would need to use a chdir to limit the source
+ path. For example, when pushing files:
+
+ > (cd /foo; rsync -avR bar/baz.c remote:/tmp/)
+
+ (Note that the parens put the two commands into a sub-shell, so that the
+ "cd" command doesn't remain in effect for future commands.) If you're
+ pulling files from an older rsync, use this idiom (but only for a
+ non-daemon transfer):
+
+ > rsync -avR --rsync-path="cd /foo; rsync" \
+ > remote:bar/baz.c /tmp/
+
+0. `--no-implied-dirs`
+
+ This option affects the default behavior of the [`--relative`](#opt) option. When
+ it is specified, the attributes of the implied directories from the source
+ names are not included in the transfer. This means that the corresponding
+ path elements on the destination system are left unchanged if they exist,
+ and any missing implied directories are created with default attributes.
+ This even allows these implied path elements to have big differences, such
+ as being a symlink to a directory on the receiving side.
+
+ For instance, if a command-line arg or a files-from entry told rsync to
+ transfer the file "path/foo/file", the directories "path" and "path/foo"
+ are implied when [`--relative`](#opt) is used. If "path/foo" is a symlink to "bar"
+ on the destination system, the receiving rsync would ordinarily delete
+ "path/foo", recreate it as a directory, and receive the file into the new
+ directory. With `--no-implied-dirs`, the receiving rsync updates
+ "path/foo/file" using the existing path elements, which means that the file
+ ends up being created in "path/bar". Another way to accomplish this link
+ preservation is to use the [`--keep-dirlinks`](#opt) option (which will also affect
+ symlinks to directories in the rest of the transfer).
+
+ When pulling files from an rsync older than 3.0.0, you may need to use this
+ option if the sending side has a symlink in the path you request and you
+ wish the implied directories to be transferred as normal directories.
+
+0. `--backup`, `-b`
+
+ With this option, preexisting destination files are renamed as each file is
+ transferred or deleted. You can control where the backup file goes and
+ what (if any) suffix gets appended using the [`--backup-dir`](#opt) and
+ [`--suffix`](#opt) options.
+
+ If you don't specify [`--backup-dir`](#opt):
+
+ 1. the [`--omit-dir-times`](#opt) option will be forced on
+ 2. the use of [`--delete`](#opt) (without [`--delete-excluded`](#opt)),
+ causes rsync to add a "protect" [filter-rule](#FILTER_RULES) for the
+ backup suffix to the end of all your existing filters that looks like
+ this: `-f "P *~"`. This rule prevents previously backed-up files from
+ being deleted.
+
+ Note that if you are supplying your own filter rules, you may need to
+ manually insert your own exclude/protect rule somewhere higher up in the
+ list so that it has a high enough priority to be effective (e.g. if your
+ rules specify a trailing inclusion/exclusion of `*`, the auto-added rule
+ would never be reached).
+
+0. `--backup-dir=DIR`
+
+ This implies the [`--backup`](#opt) option, and tells rsync to store all
+ backups in the specified directory on the receiving side. This can be used
+ for incremental backups. You can additionally specify a backup suffix
+ using the [`--suffix`](#opt) option (otherwise the files backed up in the
+ specified directory will keep their original filenames).
+
+ Note that if you specify a relative path, the backup directory will be
+ relative to the destination directory, so you probably want to specify
+ either an absolute path or a path that starts with "../". If an rsync
+ daemon is the receiver, the backup dir cannot go outside the module's path
+ hierarchy, so take extra care not to delete it or copy into it.
+
+0. `--suffix=SUFFIX`
+
+ This option allows you to override the default backup suffix used with the
+ [`--backup`](#opt) (`-b`) option. The default suffix is a `~` if no
+ [`--backup-dir`](#opt) was specified, otherwise it is an empty string.
+
+0. `--update`, `-u`
+
+ This forces rsync to skip any files which exist on the destination and have
+ a modified time that is newer than the source file. (If an existing
+ destination file has a modification time equal to the source file's, it
+ will be updated if the sizes are different.)
+
+ Note that this does not affect the copying of dirs, symlinks, or other
+ special files. Also, a difference of file format between the sender and
+ receiver is always considered to be important enough for an update, no
+ matter what date is on the objects. In other words, if the source has a
+ directory where the destination has a file, the transfer would occur
+ regardless of the timestamps.
+
+ This option is a [TRANSFER RULE](#TRANSFER_RULES), so don't expect any
+ exclude side effects.
+
+ A caution for those that choose to combine [`--inplace`](#opt) with
+ `--update`: an interrupted transfer will leave behind a partial file on the
+ receiving side that has a very recent modified time, so re-running the
+ transfer will probably **not** continue the interrupted file. As such, it
+ is usually best to avoid combining this with[ `--inplace`](#opt) unless you
+ have implemented manual steps to handle any interrupted in-progress files.
+
+0. `--inplace`
+
+ This option changes how rsync transfers a file when its data needs to be
+ updated: instead of the default method of creating a new copy of the file
+ and moving it into place when it is complete, rsync instead writes the
+ updated data directly to the destination file.
+
+ This has several effects:
+
+ - Hard links are not broken. This means the new data will be visible
+ through other hard links to the destination file. Moreover, attempts to
+ copy differing source files onto a multiply-linked destination file will
+ result in a "tug of war" with the destination data changing back and
+ forth.
+ - In-use binaries cannot be updated (either the OS will prevent this from
+ happening, or binaries that attempt to swap-in their data will misbehave
+ or crash).
+ - The file's data will be in an inconsistent state during the transfer and
+ will be left that way if the transfer is interrupted or if an update
+ fails.
+ - A file that rsync cannot write to cannot be updated. While a super user
+ can update any file, a normal user needs to be granted write permission
+ for the open of the file for writing to be successful.
+ - The efficiency of rsync's delta-transfer algorithm may be reduced if some
+ data in the destination file is overwritten before it can be copied to a
+ position later in the file. This does not apply if you use [`--backup`](#opt),
+ since rsync is smart enough to use the backup file as the basis file for
+ the transfer.
+
+ WARNING: you should not use this option to update files that are being
+ accessed by others, so be careful when choosing to use this for a copy.
+
+ This option is useful for transferring large files with block-based changes
+ or appended data, and also on systems that are disk bound, not network
+ bound. It can also help keep a copy-on-write filesystem snapshot from
+ diverging the entire contents of a file that only has minor changes.
+
+ The option implies [`--partial`](#opt) (since an interrupted transfer does
+ not delete the file), but conflicts with [`--partial-dir`](#opt) and
+ [`--delay-updates`](#opt). Prior to rsync 2.6.4 `--inplace` was also
+ incompatible with [`--compare-dest`](#opt) and [`--link-dest`](#opt).
+
+0. `--append`
+
+ This special copy mode only works to efficiently update files that are
+ known to be growing larger where any existing content on the receiving side
+ is also known to be the same as the content on the sender. The use of
+ `--append` **can be dangerous** if you aren't 100% sure that all the files
+ in the transfer are shared, growing files. You should thus use filter
+ rules to ensure that you weed out any files that do not fit this criteria.
+
+ Rsync updates these growing file in-place without verifying any of the
+ existing content in the file (it only verifies the content that it is
+ appending). Rsync skips any files that exist on the receiving side that
+ are not shorter than the associated file on the sending side (which means
+ that new files are transferred). It also skips any files whose size on the
+ sending side gets shorter during the send negotiations (rsync warns about a
+ "diminished" file when this happens).
+
+ This does not interfere with the updating of a file's non-content
+ attributes (e.g. permissions, ownership, etc.) when the file does not need
+ to be transferred, nor does it affect the updating of any directories or
+ non-regular files.
+
+0. `--append-verify`
+
+ This special copy mode works like [`--append`](#opt) except that all the
+ data in the file is included in the checksum verification (making it less
+ efficient but also potentially safer). This option **can be dangerous** if
+ you aren't 100% sure that all the files in the transfer are shared, growing
+ files. See the [`--append`](#opt) option for more details.
+
+ Note: prior to rsync 3.0.0, the [`--append`](#opt) option worked like
+ `--append-verify`, so if you are interacting with an older rsync (or the
+ transfer is using a protocol prior to 30), specifying either append option
+ will initiate an `--append-verify` transfer.
+
+0. `--dirs`, `-d`
+
+ Tell the sending side to include any directories that are encountered.
+ Unlike [`--recursive`](#opt), a directory's contents are not copied unless
+ the directory name specified is "." or ends with a trailing slash (e.g.
+ ".", "dir/.", "dir/", etc.). Without this option or the
+ [`--recursive`](#opt) option, rsync will skip all directories it encounters
+ (and output a message to that effect for each one). If you specify both
+ `--dirs` and [`--recursive`](#opt), `--recursive` takes precedence.
+
+ The `--dirs` option is implied by the [`--files-from`](#opt) option or the
+ [`--list-only`](#opt) option (including an implied [`--list-only`](#opt)
+ usage) if [`--recursive`](#opt) wasn't specified (so that directories are
+ seen in the listing). Specify `--no-dirs` (or `--no-d`) if you want to
+ turn this off.
+
+ There is also a backward-compatibility helper option, `--old-dirs`
+ (`--old-d`) that tells rsync to use a hack of `-r --exclude='/*/*'` to get
+ an older rsync to list a single directory without recursing.
+
+0. `--mkpath`
+
+ Create all missing path components of the destination path.
+
+ By default, rsync allows only the final component of the destination path
+ to not exist, which is an attempt to help you to validate your destination
+ path. With this option, rsync creates all the missing destination-path
+ components, just as if `mkdir -p $DEST_PATH` had been run on the receiving
+ side.
+
+ When specifying a destination path, including a trailing slash ensures that
+ the whole path is treated as directory names to be created, even when the
+ file list has a single item. See the [COPYING TO A DIFFERENT NAME](#)
+ section for full details on how rsync decides if a final destination-path
+ component should be created as a directory or not.
+
+ If you would like the newly-created destination dirs to match the dirs on
+ the sending side, you should be using [`--relative`](#opt) (`-R`) instead
+ of `--mkpath`. For instance, the following two commands result in the same
+ destination tree, but only the second command ensures that the
+ "some/extra/path" components match the dirs on the sending side:
+
+ > rsync -ai --mkpath host:some/extra/path/*.c some/extra/path/
+ > rsync -aiR host:some/extra/path/*.c ./
+
+0. `--links`, `-l`
+
+ Add symlinks to the transferred files instead of noisily ignoring them with
+ a "non-regular file" warning for each symlink encountered. You can
+ alternately silence the warning by specifying [`--info=nonreg0`](#opt).
+
+ The default handling of symlinks is to recreate each symlink's unchanged
+ value on the receiving side.
+
+ See the [SYMBOLIC LINKS](#) section for multi-option info.
+
+0. `--copy-links`, `-L`
+
+ The sender transforms each symlink encountered in the transfer into the
+ referent item, following the symlink chain to the file or directory that it
+ references. If a symlink chain is broken, an error is output and the file
+ is dropped from the transfer.
+
+ This option supersedes any other options that affect symlinks in the
+ transfer, since there are no symlinks left in the transfer.
+
+ This option does not change the handling of existing symlinks on the
+ receiving side, unlike versions of rsync prior to 2.6.3 which had the
+ side-effect of telling the receiving side to also follow symlinks. A
+ modern rsync won't forward this option to a remote receiver (since only the
+ sender needs to know about it), so this caveat should only affect someone
+ using an rsync client older than 2.6.7 (which is when `-L` stopped being
+ forwarded to the receiver).
+
+ See the [`--keep-dirlinks`](#opt) (`-K`) if you need a symlink to a
+ directory to be treated as a real directory on the receiving side.
+
+ See the [SYMBOLIC LINKS](#) section for multi-option info.
+
+0. `--copy-unsafe-links`
+
+ This tells rsync to copy the referent of symbolic links that point outside
+ the copied tree. Absolute symlinks are also treated like ordinary files,
+ and so are any symlinks in the source path itself when [`--relative`](#opt)
+ is used.
+
+ Note that the cut-off point is the top of the transfer, which is the part
+ of the path that rsync isn't mentioning in the verbose output. If you copy
+ "/src/subdir" to "/dest/" then the "subdir" directory is a name inside the
+ transfer tree, not the top of the transfer (which is /src) so it is legal
+ for created relative symlinks to refer to other names inside the /src and
+ /dest directories. If you instead copy "/src/subdir/" (with a trailing
+ slash) to "/dest/subdir" that would not allow symlinks to any files outside
+ of "subdir".
+
+ Note that safe symlinks are only copied if [`--links`](#opt) was also
+ specified or implied. The `--copy-unsafe-links` option has no extra effect
+ when combined with [`--copy-links`](#opt).
+
+ See the [SYMBOLIC LINKS](#) section for multi-option info.
+
+0. `--safe-links`
+
+ This tells the receiving rsync to ignore any symbolic links in the transfer
+ which point outside the copied tree. All absolute symlinks are also
+ ignored.
+
+ Since this ignoring is happening on the receiving side, it will still be
+ effective even when the sending side has munged symlinks (when it is using
+ [`--munge-links`](#opt)). It also affects deletions, since the file being
+ present in the transfer prevents any matching file on the receiver from
+ being deleted when the symlink is deemed to be unsafe and is skipped.
+
+ This option must be combined with [`--links`](#opt) (or
+ [`--archive`](#opt)) to have any symlinks in the transfer to conditionally
+ ignore. Its effect is superseded by [`--copy-unsafe-links`](#opt).
+
+ Using this option in conjunction with [`--relative`](#opt) may give
+ unexpected results.
+
+ See the [SYMBOLIC LINKS](#) section for multi-option info.
+
+0. `--munge-links`
+
+ This option affects just one side of the transfer and tells rsync to munge
+ symlink values when it is receiving files or unmunge symlink values when it
+ is sending files. The munged values make the symlinks unusable on disk but
+ allows the original contents of the symlinks to be recovered.
+
+ The server-side rsync often enables this option without the client's
+ knowledge, such as in an rsync daemon's configuration file or by an option
+ given to the rrsync (restricted rsync) script. When specified on the
+ client side, specify the option normally if it is the client side that
+ has/needs the munged symlinks, or use `-M--munge-links` to give the option
+ to the server when it has/needs the munged symlinks. Note that on a local
+ transfer, the client is the sender, so specifying the option directly
+ unmunges symlinks while specifying it as a remote option munges symlinks.
+
+ This option has no effect when sent to a daemon via [`--remote-option`](#opt)
+ because the daemon configures whether it wants munged symlinks via its
+ "`munge symlinks`" parameter.
+
+ The symlink value is munged/unmunged once it is in the transfer, so any
+ option that transforms symlinks into non-symlinks occurs prior to the
+ munging/unmunging **except** for [`--safe-links`](#opt), which is a choice
+ that the receiver makes, so it bases its decision on the munged/unmunged
+ value. This does mean that if a receiver has munging enabled, that using
+ [`--safe-links`](#opt) will cause all symlinks to be ignored (since they
+ are all absolute).
+
+ The method that rsync uses to munge the symlinks is to prefix each one's
+ value with the string "/rsyncd-munged/". This prevents the links from
+ being used as long as the directory does not exist. When this option is
+ enabled, rsync will refuse to run if that path is a directory or a symlink
+ to a directory (though it only checks at startup). See also the
+ "munge-symlinks" python script in the support directory of the source code
+ for a way to munge/unmunge one or more symlinks in-place.
+
+0. `--copy-dirlinks`, `-k`
+
+ This option causes the sending side to treat a symlink to a directory as
+ though it were a real directory. This is useful if you don't want symlinks
+ to non-directories to be affected, as they would be using
+ [`--copy-links`](#opt).
+
+ Without this option, if the sending side has replaced a directory with a
+ symlink to a directory, the receiving side will delete anything that is in
+ the way of the new symlink, including a directory hierarchy (as long as
+ [`--force`](#opt) or [`--delete`](#opt) is in effect).
+
+ See also [`--keep-dirlinks`](#opt) for an analogous option for the
+ receiving side.
+
+ `--copy-dirlinks` applies to all symlinks to directories in the source. If
+ you want to follow only a few specified symlinks, a trick you can use is to
+ pass them as additional source args with a trailing slash, using
+ [`--relative`](#opt) to make the paths match up right. For example:
+
+ > rsync -r --relative src/./ src/./follow-me/ dest/
+
+ This works because rsync calls **lstat**(2) on the source arg as given, and
+ the trailing slash makes **lstat**(2) follow the symlink, giving rise to a
+ directory in the file-list which overrides the symlink found during the
+ scan of "src/./".
+
+ See the [SYMBOLIC LINKS](#) section for multi-option info.
+
+0. `--keep-dirlinks`, `-K`
+
+ This option causes the receiving side to treat a symlink to a directory as
+ though it were a real directory, but only if it matches a real directory
+ from the sender. Without this option, the receiver's symlink would be
+ deleted and replaced with a real directory.
+
+ For example, suppose you transfer a directory "foo" that contains a file
+ "file", but "foo" is a symlink to directory "bar" on the receiver. Without
+ `--keep-dirlinks`, the receiver deletes symlink "foo", recreates it as a
+ directory, and receives the file into the new directory. With
+ `--keep-dirlinks`, the receiver keeps the symlink and "file" ends up in
+ "bar".
+
+ One note of caution: if you use `--keep-dirlinks`, you must trust all the
+ symlinks in the copy or enable the [`--munge-links`](#opt) option on the
+ receiving side! If it is possible for an untrusted user to create their
+ own symlink to any real directory, the user could then (on a subsequent
+ copy) replace the symlink with a real directory and affect the content of
+ whatever directory the symlink references. For backup copies, you are
+ better off using something like a bind mount instead of a symlink to modify
+ your receiving hierarchy.
+
+ See also [`--copy-dirlinks`](#opt) for an analogous option for the sending
+ side.
+
+ See the [SYMBOLIC LINKS](#) section for multi-option info.
+
+0. `--hard-links`, `-H`
+
+ This tells rsync to look for hard-linked files in the source and link
+ together the corresponding files on the destination. Without this option,
+ hard-linked files in the source are treated as though they were separate
+ files.
+
+ This option does NOT necessarily ensure that the pattern of hard links on
+ the destination exactly matches that on the source. Cases in which the
+ destination may end up with extra hard links include the following:
+
+ - If the destination contains extraneous hard-links (more linking than what
+ is present in the source file list), the copying algorithm will not break
+ them explicitly. However, if one or more of the paths have content
+ differences, the normal file-update process will break those extra links
+ (unless you are using the [`--inplace`](#opt) option).
+ - If you specify a [`--link-dest`](#opt) directory that contains hard
+ links, the linking of the destination files against the
+ [`--link-dest`](#opt) files can cause some paths in the destination to
+ become linked together due to the [`--link-dest`](#opt) associations.
+
+ Note that rsync can only detect hard links between files that are inside
+ the transfer set. If rsync updates a file that has extra hard-link
+ connections to files outside the transfer, that linkage will be broken. If
+ you are tempted to use the [`--inplace`](#opt) option to avoid this breakage, be
+ very careful that you know how your files are being updated so that you are
+ certain that no unintended changes happen due to lingering hard links (and
+ see the [`--inplace`](#opt) option for more caveats).
+
+ If incremental recursion is active (see [`--inc-recursive`](#opt)), rsync
+ may transfer a missing hard-linked file before it finds that another link
+ for that contents exists elsewhere in the hierarchy. This does not affect
+ the accuracy of the transfer (i.e. which files are hard-linked together),
+ just its efficiency (i.e. copying the data for a new, early copy of a
+ hard-linked file that could have been found later in the transfer in
+ another member of the hard-linked set of files). One way to avoid this
+ inefficiency is to disable incremental recursion using the
+ [`--no-inc-recursive`](#opt) option.
+
+0. `--perms`, `-p`
+
+ This option causes the receiving rsync to set the destination permissions
+ to be the same as the source permissions. (See also the [`--chmod`](#opt)
+ option for a way to modify what rsync considers to be the source
+ permissions.)
+
+ When this option is _off_, permissions are set as follows:
+
+ - Existing files (including updated files) retain their existing
+ permissions, though the [`--executability`](#opt) option might change
+ just the execute permission for the file.
+ - New files get their "normal" permission bits set to the source file's
+ permissions masked with the receiving directory's default permissions
+ (either the receiving process's umask, or the permissions specified via
+ the destination directory's default ACL), and their special permission
+ bits disabled except in the case where a new directory inherits a setgid
+ bit from its parent directory.
+
+ Thus, when `--perms` and [`--executability`](#opt) are both disabled, rsync's
+ behavior is the same as that of other file-copy utilities, such as **cp**(1)
+ and **tar**(1).
+
+ In summary: to give destination files (both old and new) the source
+ permissions, use `--perms`. To give new files the destination-default
+ permissions (while leaving existing files unchanged), make sure that the
+ `--perms` option is off and use [`--chmod=ugo=rwX`](#opt) (which ensures
+ that all non-masked bits get enabled). If you'd care to make this latter
+ behavior easier to type, you could define a popt alias for it, such as
+ putting this line in the file `~/.popt` (the following defines the `-Z`
+ option, and includes `--no-g` to use the default group of the destination
+ dir):
+
+ > rsync alias -Z --no-p --no-g --chmod=ugo=rwX
+
+ You could then use this new option in a command such as this one:
+
+ > rsync -avZ src/ dest/
+
+ (Caveat: make sure that `-a` does not follow `-Z`, or it will re-enable the
+ two `--no-*` options mentioned above.)
+
+ The preservation of the destination's setgid bit on newly-created
+ directories when `--perms` is off was added in rsync 2.6.7. Older rsync
+ versions erroneously preserved the three special permission bits for
+ newly-created files when `--perms` was off, while overriding the
+ destination's setgid bit setting on a newly-created directory. Default ACL
+ observance was added to the ACL patch for rsync 2.6.7, so older (or
+ non-ACL-enabled) rsyncs use the umask even if default ACLs are present.
+ (Keep in mind that it is the version of the receiving rsync that affects
+ these behaviors.)
+
+0. `--executability`, `-E`
+
+ This option causes rsync to preserve the executability (or
+ non-executability) of regular files when [`--perms`](#opt) is not enabled.
+ A regular file is considered to be executable if at least one 'x' is turned
+ on in its permissions. When an existing destination file's executability
+ differs from that of the corresponding source file, rsync modifies the
+ destination file's permissions as follows:
+
+ - To make a file non-executable, rsync turns off all its 'x' permissions.
+ - To make a file executable, rsync turns on each 'x' permission that has a
+ corresponding 'r' permission enabled.
+
+ If [`--perms`](#opt) is enabled, this option is ignored.
+
+0. `--acls`, `-A`
+
+ This option causes rsync to update the destination ACLs to be the same as
+ the source ACLs. The option also implies [`--perms`](#opt).
+
+ The source and destination systems must have compatible ACL entries for
+ this option to work properly. See the [`--fake-super`](#opt) option for a
+ way to backup and restore ACLs that are not compatible.
+
+0. `--xattrs`, `-X`
+
+ This option causes rsync to update the destination extended attributes to
+ be the same as the source ones.
+
+ For systems that support extended-attribute namespaces, a copy being done
+ by a super-user copies all namespaces except system.\*. A normal user only
+ copies the user.\* namespace. To be able to backup and restore non-user
+ namespaces as a normal user, see the [`--fake-super`](#opt) option.
+
+ The above name filtering can be overridden by using one or more filter
+ options with the **x** modifier. When you specify an xattr-affecting
+ filter rule, rsync requires that you do your own system/user filtering, as
+ well as any additional filtering for what xattr names are copied and what
+ names are allowed to be deleted. For example, to skip the system
+ namespace, you could specify:
+
+ > --filter='-x system.*'
+
+ To skip all namespaces except the user namespace, you could specify a
+ negated-user match:
+
+ > --filter='-x! user.*'
+
+ To prevent any attributes from being deleted, you could specify a
+ receiver-only rule that excludes all names:
+
+ > --filter='-xr *'
+
+ Note that the `-X` option does not copy rsync's special xattr values (e.g.
+ those used by [`--fake-super`](#opt)) unless you repeat the option (e.g. `-XX`).
+ This "copy all xattrs" mode cannot be used with [`--fake-super`](#opt).
+
+0. `--chmod=CHMOD`
+
+ This option tells rsync to apply one or more comma-separated "chmod" modes
+ to the permission of the files in the transfer. The resulting value is
+ treated as though it were the permissions that the sending side supplied
+ for the file, which means that this option can seem to have no effect on
+ existing files if [`--perms`](#opt) is not enabled.
+
+ In addition to the normal parsing rules specified in the **chmod**(1)
+ manpage, you can specify an item that should only apply to a directory by
+ prefixing it with a 'D', or specify an item that should only apply to a
+ file by prefixing it with a 'F'. For example, the following will ensure
+ that all directories get marked set-gid, that no files are other-writable,
+ that both are user-writable and group-writable, and that both have
+ consistent executability across all bits:
+
+ > --chmod=Dg+s,ug+w,Fo-w,+X
+
+ Using octal mode numbers is also allowed:
+
+ > --chmod=D2775,F664
+
+ It is also legal to specify multiple `--chmod` options, as each additional
+ option is just appended to the list of changes to make.
+
+ See the [`--perms`](#opt) and [`--executability`](#opt) options for how the
+ resulting permission value can be applied to the files in the transfer.
+
+0. `--owner`, `-o`
+
+ This option causes rsync to set the owner of the destination file to be the
+ same as the source file, but only if the receiving rsync is being run as
+ the super-user (see also the [`--super`](#opt) and [`--fake-super`](#opt)
+ options). Without this option, the owner of new and/or transferred files
+ are set to the invoking user on the receiving side.
+
+ The preservation of ownership will associate matching names by default, but
+ may fall back to using the ID number in some circumstances (see also the
+ [`--numeric-ids`](#opt) option for a full discussion).
+
+0. `--group`, `-g`
+
+ This option causes rsync to set the group of the destination file to be the
+ same as the source file. If the receiving program is not running as the
+ super-user (or if `--no-super` was specified), only groups that the
+ invoking user on the receiving side is a member of will be preserved.
+ Without this option, the group is set to the default group of the invoking
+ user on the receiving side.
+
+ The preservation of group information will associate matching names by
+ default, but may fall back to using the ID number in some circumstances
+ (see also the [`--numeric-ids`](#opt) option for a full discussion).
+
+0. `--devices`
+
+ This option causes rsync to transfer character and block device files to
+ the remote system to recreate these devices. If the receiving rsync is not
+ being run as the super-user, rsync silently skips creating the device files
+ (see also the [`--super`](#opt) and [`--fake-super`](#opt) options).
+
+ By default, rsync generates a "non-regular file" warning for each device
+ file encountered when this option is not set. You can silence the warning
+ by specifying [`--info=nonreg0`](#opt).
+
+0. `--specials`
+
+ This option causes rsync to transfer special files, such as named sockets
+ and fifos. If the receiving rsync is not being run as the super-user,
+ rsync silently skips creating the special files (see also the
+ [`--super`](#opt) and [`--fake-super`](#opt) options).
+
+ By default, rsync generates a "non-regular file" warning for each special
+ file encountered when this option is not set. You can silence the warning
+ by specifying [`--info=nonreg0`](#opt).
+
+0. `-D`
+
+ The `-D` option is equivalent to "[`--devices`](#opt)
+ [`--specials`](#opt)".
+
+0. `--copy-devices`
+
+ This tells rsync to treat a device on the sending side as a regular file,
+ allowing it to be copied to a normal destination file (or another device
+ if `--write-devices` was also specified).
+
+ This option is refused by default by an rsync daemon.
+
+0. `--write-devices`
+
+ This tells rsync to treat a device on the receiving side as a regular file,
+ allowing the writing of file data into a device.
+
+ This option implies the [`--inplace`](#opt) option.
+
+ Be careful using this, as you should know what devices are present on the
+ receiving side of the transfer, especially when running rsync as root.
+
+ This option is refused by default by an rsync daemon.
+
+0. `--times`, `-t`
+
+ This tells rsync to transfer modification times along with the files and
+ update them on the remote system. Note that if this option is not used,
+ the optimization that excludes files that have not been modified cannot be
+ effective; in other words, a missing `-t` (or [`-a`](#opt)) will cause the
+ next transfer to behave as if it used [`--ignore-times`](#opt) (`-I`),
+ causing all files to be updated (though rsync's delta-transfer algorithm
+ will make the update fairly efficient if the files haven't actually
+ changed, you're much better off using `-t`).
+
+ A modern rsync that is using transfer protocol 30 or 31 conveys a modify
+ time using up to 8-bytes. If rsync is forced to speak an older protocol
+ (perhaps due to the remote rsync being older than 3.0.0) a modify time is
+ conveyed using 4-bytes. Prior to 3.2.7, these shorter values could convey
+ a date range of 13-Dec-1901 to 19-Jan-2038. Beginning with 3.2.7, these
+ 4-byte values now convey a date range of 1-Jan-1970 to 7-Feb-2106. If you
+ have files dated older than 1970, make sure your rsync executables are
+ upgraded so that the full range of dates can be conveyed.
+
+0. `--atimes`, `-U`
+
+ This tells rsync to set the access (use) times of the destination files to
+ the same value as the source files.
+
+ If repeated, it also sets the [`--open-noatime`](#opt) option, which can help you
+ to make the sending and receiving systems have the same access times on the
+ transferred files without needing to run rsync an extra time after a file
+ is transferred.
+
+ Note that some older rsync versions (prior to 3.2.0) may have been built
+ with a pre-release `--atimes` patch that does not imply
+ [`--open-noatime`](#opt) when this option is repeated.
+
+0. `--open-noatime`
+
+ This tells rsync to open files with the O_NOATIME flag (on systems that
+ support it) to avoid changing the access time of the files that are being
+ transferred. If your OS does not support the O_NOATIME flag then rsync
+ will silently ignore this option. Note also that some filesystems are
+ mounted to avoid updating the atime on read access even without the
+ O_NOATIME flag being set.
+
+0. `--crtimes`, `-N,`
+
+ This tells rsync to set the create times (newness) of the destination
+ files to the same value as the source files.
+
+0. `--omit-dir-times`, `-O`
+
+ This tells rsync to omit directories when it is preserving modification,
+ access, and create times. If NFS is sharing the directories on the receiving
+ side, it is a good idea to use `-O`. This option is inferred if you use
+ [`--backup`](#opt) without [`--backup-dir`](#opt).
+
+ This option also has the side-effect of avoiding early creation of missing
+ sub-directories when incremental recursion is enabled, as discussed in the
+ [`--inc-recursive`](#opt) section.
+
+0. `--omit-link-times`, `-J`
+
+ This tells rsync to omit symlinks when it is preserving modification,
+ access, and create times.
+
+0. `--super`
+
+ This tells the receiving side to attempt super-user activities even if the
+ receiving rsync wasn't run by the super-user. These activities include:
+ preserving users via the [`--owner`](#opt) option, preserving all groups
+ (not just the current user's groups) via the [`--group`](#opt) option, and
+ copying devices via the [`--devices`](#opt) option. This is useful for
+ systems that allow such activities without being the super-user, and also
+ for ensuring that you will get errors if the receiving side isn't being run
+ as the super-user. To turn off super-user activities, the super-user can
+ use `--no-super`.
+
+0. `--fake-super`
+
+ When this option is enabled, rsync simulates super-user activities by
+ saving/restoring the privileged attributes via special extended attributes
+ that are attached to each file (as needed). This includes the file's owner
+ and group (if it is not the default), the file's device info (device &
+ special files are created as empty text files), and any permission bits
+ that we won't allow to be set on the real file (e.g. the real file gets
+ u-s,g-s,o-t for safety) or that would limit the owner's access (since the
+ real super-user can always access/change a file, the files we create can
+ always be accessed/changed by the creating user). This option also handles
+ ACLs (if [`--acls`](#opt) was specified) and non-user extended attributes
+ (if [`--xattrs`](#opt) was specified).
+
+ This is a good way to backup data without using a super-user, and to store
+ ACLs from incompatible systems.
+
+ The `--fake-super` option only affects the side where the option is used.
+ To affect the remote side of a remote-shell connection, use the
+ [`--remote-option`](#opt) (`-M`) option:
+
+ > rsync -av -M--fake-super /src/ host:/dest/
+
+ For a local copy, this option affects both the source and the destination.
+ If you wish a local copy to enable this option just for the destination
+ files, specify `-M--fake-super`. If you wish a local copy to enable this
+ option just for the source files, combine `--fake-super` with `-M--super`.
+
+ This option is overridden by both [`--super`](#opt) and `--no-super`.
+
+ See also the [`fake super`](rsyncd.conf.5#fake_super) setting in the
+ daemon's rsyncd.conf file.
+
+0. `--sparse`, `-S`
+
+ Try to handle sparse files efficiently so they take up less space on the
+ destination. If combined with [`--inplace`](#opt) the file created might
+ not end up with sparse blocks with some combinations of kernel version
+ and/or filesystem type. If [`--whole-file`](#opt) is in effect (e.g. for a
+ local copy) then it will always work because rsync truncates the file prior
+ to writing out the updated version.
+
+ Note that versions of rsync older than 3.1.3 will reject the combination of
+ `--sparse` and [`--inplace`](#opt).
+
+0. `--preallocate`
+
+ This tells the receiver to allocate each destination file to its eventual
+ size before writing data to the file. Rsync will only use the real
+ filesystem-level preallocation support provided by Linux's **fallocate**(2)
+ system call or Cygwin's **posix_fallocate**(3), not the slow glibc
+ implementation that writes a null byte into each block.
+
+ Without this option, larger files may not be entirely contiguous on the
+ filesystem, but with this option rsync will probably copy more slowly. If
+ the destination is not an extent-supporting filesystem (such as ext4, xfs,
+ NTFS, etc.), this option may have no positive effect at all.
+
+ If combined with [`--sparse`](#opt), the file will only have sparse blocks
+ (as opposed to allocated sequences of null bytes) if the kernel version and
+ filesystem type support creating holes in the allocated data.
+
+0. `--dry-run`, `-n`
+
+ This makes rsync perform a trial run that doesn't make any changes (and
+ produces mostly the same output as a real run). It is most commonly used
+ in combination with the [`--verbose`](#opt) (`-v`) and/or
+ [`--itemize-changes`](#opt) (`-i`) options to see what an rsync command is
+ going to do before one actually runs it.
+
+ The output of [`--itemize-changes`](#opt) is supposed to be exactly the
+ same on a dry run and a subsequent real run (barring intentional trickery
+ and system call failures); if it isn't, that's a bug. Other output should
+ be mostly unchanged, but may differ in some areas. Notably, a dry run does
+ not send the actual data for file transfers, so [`--progress`](#opt) has no
+ effect, the "bytes sent", "bytes received", "literal data", and "matched
+ data" statistics are too small, and the "speedup" value is equivalent to a
+ run where no file transfers were needed.
+
+0. `--whole-file`, `-W`
+
+ This option disables rsync's delta-transfer algorithm, which causes all
+ transferred files to be sent whole. The transfer may be faster if this
+ option is used when the bandwidth between the source and destination
+ machines is higher than the bandwidth to disk (especially when the "disk"
+ is actually a networked filesystem). This is the default when both the
+ source and destination are specified as local paths, but only if no
+ batch-writing option is in effect.
+
+0. `--no-whole-file`, `--no-W`
+
+ Disable whole-file updating when it is enabled by default for a local
+ transfer. This usually slows rsync down, but it can be useful if you are
+ trying to minimize the writes to the destination file (if combined with
+ [`--inplace`](#opt)) or for testing the checksum-based update algorithm.
+
+ See also the [`--whole-file`](#opt) option.
+
+0. `--checksum-choice=STR`, `--cc=STR`
+
+ This option overrides the checksum algorithms. If one algorithm name is
+ specified, it is used for both the transfer checksums and (assuming
+ [`--checksum`](#opt) is specified) the pre-transfer checksums. If two
+ comma-separated names are supplied, the first name affects the transfer
+ checksums, and the second name affects the pre-transfer checksums (`-c`).
+
+ The checksum options that you may be able to use are:
+
+ - `auto` (the default automatic choice)
+ - `xxh128`
+ - `xxh3`
+ - `xxh64` (aka `xxhash`)
+ - `md5`
+ - `md4`
+ - `sha1`
+ - `none`
+
+ Run `rsync --version` to see the default checksum list compiled into your
+ version (which may differ from the list above).
+
+ If "none" is specified for the first (or only) name, the [`--whole-file`](#opt)
+ option is forced on and no checksum verification is performed on the
+ transferred data. If "none" is specified for the second (or only) name,
+ the [`--checksum`](#opt) option cannot be used.
+
+ The "auto" option is the default, where rsync bases its algorithm choice on
+ a negotiation between the client and the server as follows:
+
+ When both sides of the transfer are at least 3.2.0, rsync chooses the first
+ algorithm in the client's list of choices that is also in the server's list
+ of choices. If no common checksum choice is found, rsync exits with
+ an error. If the remote rsync is too old to support checksum negotiation,
+ a value is chosen based on the protocol version (which chooses between MD5
+ and various flavors of MD4 based on protocol age).
+
+ The default order can be customized by setting the environment variable
+ [`RSYNC_CHECKSUM_LIST`](#) to a space-separated list of acceptable checksum
+ names. If the string contains a "`&`" character, it is separated into the
+ "client string & server string", otherwise the same string applies to both.
+ If the string (or string portion) contains no non-whitespace characters,
+ the default checksum list is used. This method does not allow you to
+ specify the transfer checksum separately from the pre-transfer checksum,
+ and it discards "auto" and all unknown checksum names. A list with only
+ invalid names results in a failed negotiation.
+
+ The use of the `--checksum-choice` option overrides this environment list.
+
+0. `--one-file-system`, `-x`
+
+ This tells rsync to avoid crossing a filesystem boundary when recursing.
+ This does not limit the user's ability to specify items to copy from
+ multiple filesystems, just rsync's recursion through the hierarchy of each
+ directory that the user specified, and also the analogous recursion on the
+ receiving side during deletion. Also keep in mind that rsync treats a
+ "bind" mount to the same device as being on the same filesystem.
+
+ If this option is repeated, rsync omits all mount-point directories from
+ the copy. Otherwise, it includes an empty directory at each mount-point it
+ encounters (using the attributes of the mounted directory because those of
+ the underlying mount-point directory are inaccessible).
+
+ If rsync has been told to collapse symlinks (via [`--copy-links`](#opt) or
+ [`--copy-unsafe-links`](#opt)), a symlink to a directory on another device
+ is treated like a mount-point. Symlinks to non-directories are unaffected
+ by this option.
+
+0. `--ignore-non-existing`, `--existing`
+
+ This tells rsync to skip creating files (including directories) that do not
+ exist yet on the destination. If this option is combined with the
+ [`--ignore-existing`](#opt) option, no files will be updated (which can be
+ useful if all you want to do is delete extraneous files).
+
+ This option is a [TRANSFER RULE](#TRANSFER_RULES), so don't expect any
+ exclude side effects.
+
+0. `--ignore-existing`
+
+ This tells rsync to skip updating files that already exist on the
+ destination (this does _not_ ignore existing directories, or nothing would
+ get done). See also [`--ignore-non-existing`](#opt).
+
+ This option is a [TRANSFER RULE](#TRANSFER_RULES), so don't expect any
+ exclude side effects.
+
+ This option can be useful for those doing backups using the
+ [`--link-dest`](#opt) option when they need to continue a backup run that
+ got interrupted. Since a [`--link-dest`](#opt) run is copied into a new
+ directory hierarchy (when it is used properly), using [`--ignore-existing`
+ will ensure that the already-handled files don't get tweaked (which avoids
+ a change in permissions on the hard-linked files). This does mean that
+ this option is only looking at the existing files in the destination
+ hierarchy itself.
+
+ When [`--info=skip2`](#opt) is used rsync will output "FILENAME exists
+ (INFO)" messages where the INFO indicates one of "type change", "sum
+ change" (requires [`-c`](#opt)), "file change" (based on the quick check),
+ "attr change", or "uptodate". Using [`--info=skip1`](#opt) (which is also
+ implied by 2 [`-v`](#opt) options) outputs the exists message without the
+ INFO suffix.
+
+0. `--remove-source-files`
+
+ This tells rsync to remove from the sending side the files (meaning
+ non-directories) that are a part of the transfer and have been successfully
+ duplicated on the receiving side.
+
+ Note that you should only use this option on source files that are
+ quiescent. If you are using this to move files that show up in a
+ particular directory over to another host, make sure that the finished
+ files get renamed into the source directory, not directly written into it,
+ so that rsync can't possibly transfer a file that is not yet fully written.
+ If you can't first write the files into a different directory, you should
+ use a naming idiom that lets rsync avoid transferring files that are not
+ yet finished (e.g. name the file "foo.new" when it is written, rename it to
+ "foo" when it is done, and then use the option [`--exclude='*.new'`](#opt)
+ for the rsync transfer).
+
+ Starting with 3.1.0, rsync will skip the sender-side removal (and output an
+ error) if the file's size or modify time has not stayed unchanged.
+
+ Starting with 3.2.6, a local rsync copy will ensure that the sender does
+ not remove a file the receiver just verified, such as when the user
+ accidentally makes the source and destination directory the same path.
+
+0. `--delete`
+
+ This tells rsync to delete extraneous files from the receiving side (ones
+ that aren't on the sending side), but only for the directories that are
+ being synchronized. You must have asked rsync to send the whole directory
+ (e.g. "`dir`" or "`dir/`") without using a wildcard for the directory's
+ contents (e.g. "`dir/*`") since the wildcard is expanded by the shell and
+ rsync thus gets a request to transfer individual files, not the files'
+ parent directory. Files that are excluded from the transfer are also
+ excluded from being deleted unless you use the [`--delete-excluded`](#opt)
+ option or mark the rules as only matching on the sending side (see the
+ include/exclude modifiers in the [FILTER RULES](#) section).
+
+ Prior to rsync 2.6.7, this option would have no effect unless
+ [`--recursive`](#opt) was enabled. Beginning with 2.6.7, deletions will
+ also occur when [`--dirs`](#opt) (`-d`) is enabled, but only for
+ directories whose contents are being copied.
+
+ This option can be dangerous if used incorrectly! It is a very good idea to
+ first try a run using the [`--dry-run`](#opt) (`-n`) option to see what
+ files are going to be deleted.
+
+ If the sending side detects any I/O errors, then the deletion of any files
+ at the destination will be automatically disabled. This is to prevent
+ temporary filesystem failures (such as NFS errors) on the sending side from
+ causing a massive deletion of files on the destination. You can override
+ this with the [`--ignore-errors`](#opt) option.
+
+ The `--delete` option may be combined with one of the --delete-WHEN options
+ without conflict, as well as [`--delete-excluded`](#opt). However, if none
+ of the `--delete-WHEN` options are specified, rsync will choose the
+ [`--delete-during`](#opt) algorithm when talking to rsync 3.0.0 or newer,
+ or the [`--delete-before`](#opt) algorithm when talking to an older rsync.
+ See also [`--delete-delay`](#opt) and [`--delete-after`](#opt).
+
+0. `--delete-before`
+
+ Request that the file-deletions on the receiving side be done before the
+ transfer starts. See [`--delete`](#opt) (which is implied) for more
+ details on file-deletion.
+
+ Deleting before the transfer is helpful if the filesystem is tight for
+ space and removing extraneous files would help to make the transfer
+ possible. However, it does introduce a delay before the start of the
+ transfer, and this delay might cause the transfer to timeout (if
+ [`--timeout`](#opt) was specified). It also forces rsync to use the old,
+ non-incremental recursion algorithm that requires rsync to scan all the
+ files in the transfer into memory at once (see [`--recursive`](#opt)).
+
+0. `--delete-during`, `--del`
+
+ Request that the file-deletions on the receiving side be done incrementally
+ as the transfer happens. The per-directory delete scan is done right
+ before each directory is checked for updates, so it behaves like a more
+ efficient [`--delete-before`](#opt), including doing the deletions prior to
+ any per-directory filter files being updated. This option was first added
+ in rsync version 2.6.4. See [`--delete`](#opt) (which is implied) for more
+ details on file-deletion.
+
+0. `--delete-delay`
+
+ Request that the file-deletions on the receiving side be computed during
+ the transfer (like [`--delete-during`](#opt)), and then removed after the
+ transfer completes. This is useful when combined with
+ [`--delay-updates`](#opt) and/or [`--fuzzy`](#opt), and is more efficient
+ than using [`--delete-after`](#opt) (but can behave differently, since
+ [`--delete-after`](#opt) computes the deletions in a separate pass after
+ all updates are done). If the number of removed files overflows an
+ internal buffer, a temporary file will be created on the receiving side to
+ hold the names (it is removed while open, so you shouldn't see it during
+ the transfer). If the creation of the temporary file fails, rsync will try
+ to fall back to using [`--delete-after`](#opt) (which it cannot do if
+ [`--recursive`](#opt) is doing an incremental scan). See
+ [`--delete`](#opt) (which is implied) for more details on file-deletion.
+
+0. `--delete-after`
+
+ Request that the file-deletions on the receiving side be done after the
+ transfer has completed. This is useful if you are sending new
+ per-directory merge files as a part of the transfer and you want their
+ exclusions to take effect for the delete phase of the current transfer. It
+ also forces rsync to use the old, non-incremental recursion algorithm that
+ requires rsync to scan all the files in the transfer into memory at once
+ (see [`--recursive`](#opt)). See [`--delete`](#opt) (which is implied) for
+ more details on file-deletion.
+
+ See also the [`--delete-delay`](#opt) option that might be a faster choice
+ for those that just want the deletions to occur at the end of the transfer.
+
+0. `--delete-excluded`
+
+ This option turns any unqualified exclude/include rules into server-side
+ rules that do not affect the receiver's deletions.
+
+ By default, an exclude or include has both a server-side effect (to "hide"
+ and "show" files when building the server's file list) and a receiver-side
+ effect (to "protect" and "risk" files when deletions are occurring). Any
+ rule that has no modifier to specify what sides it is executed on will be
+ instead treated as if it were a server-side rule only, avoiding any
+ "protect" effects of the rules.
+
+ A rule can still apply to both sides even with this option specified if the
+ rule is given both the sender & receiver modifier letters (e.g., `-f'-sr
+ foo'`). Receiver-side protect/risk rules can also be explicitly specified
+ to limit the deletions. This saves you from having to edit a bunch of
+ `-f'- foo'` rules into `-f'-s foo'` (aka `-f'H foo'`) rules (not to mention
+ the corresponding includes).
+
+ See the [FILTER RULES](#) section for more information. See
+ [`--delete`](#opt) (which is implied) for more details on deletion.
+
+0. `--ignore-missing-args`
+
+ When rsync is first processing the explicitly requested source files (e.g.
+ command-line arguments or [`--files-from`](#opt) entries), it is normally
+ an error if the file cannot be found. This option suppresses that error,
+ and does not try to transfer the file. This does not affect subsequent
+ vanished-file errors if a file was initially found to be present and later
+ is no longer there.
+
+0. `--delete-missing-args`
+
+ This option takes the behavior of the (implied)
+ [`--ignore-missing-args`](#opt) option a step farther: each missing arg
+ will become a deletion request of the corresponding destination file on the
+ receiving side (should it exist). If the destination file is a non-empty
+ directory, it will only be successfully deleted if [`--force`](#opt) or
+ [`--delete`](#opt) are in effect. Other than that, this option is
+ independent of any other type of delete processing.
+
+ The missing source files are represented by special file-list entries which
+ display as a "`*missing`" entry in the [`--list-only`](#opt) output.
+
+0. `--ignore-errors`
+
+ Tells [`--delete`](#opt) to go ahead and delete files even when there are
+ I/O errors.
+
+0. `--force`
+
+ This option tells rsync to delete a non-empty directory when it is to be
+ replaced by a non-directory. This is only relevant if deletions are not
+ active (see [`--delete`](#opt) for details).
+
+ Note for older rsync versions: `--force` used to still be required when
+ using [`--delete-after`](#opt), and it used to be non-functional unless the
+ [`--recursive`](#opt) option was also enabled.
+
+0. `--max-delete=NUM`
+
+ This tells rsync not to delete more than NUM files or directories. If that
+ limit is exceeded, all further deletions are skipped through the end of the
+ transfer. At the end, rsync outputs a warning (including a count of the
+ skipped deletions) and exits with an error code of 25 (unless some more
+ important error condition also occurred).
+
+ Beginning with version 3.0.0, you may specify `--max-delete=0` to be warned
+ about any extraneous files in the destination without removing any of them.
+ Older clients interpreted this as "unlimited", so if you don't know what
+ version the client is, you can use the less obvious `--max-delete=-1` as a
+ backward-compatible way to specify that no deletions be allowed (though
+ really old versions didn't warn when the limit was exceeded).
+
+0. `--max-size=SIZE`
+
+ This tells rsync to avoid transferring any file that is larger than the
+ specified SIZE. A numeric value can be suffixed with a string to indicate
+ the numeric units or left unqualified to specify bytes. Feel free to use a
+ fractional value along with the units, such as `--max-size=1.5m`.
+
+ This option is a [TRANSFER RULE](#TRANSFER_RULES), so don't expect any
+ exclude side effects.
+
+ The first letter of a units string can be `B` (bytes), `K` (kilo), `M`
+ (mega), `G` (giga), `T` (tera), or `P` (peta). If the string is a single
+ char or has "ib" added to it (e.g. "G" or "GiB") then the units are
+ multiples of 1024. If you use a two-letter suffix that ends with a "B"
+ (e.g. "kb") then you get units that are multiples of 1000. The string's
+ letters can be any mix of upper and lower-case that you want to use.
+
+ Finally, if the string ends with either "+1" or "-1", it is offset by one
+ byte in the indicated direction. The largest possible value is usually
+ `8192P-1`.
+
+ Examples: `--max-size=1.5mb-1` is 1499999 bytes, and `--max-size=2g+1` is
+ 2147483649 bytes.
+
+ Note that rsync versions prior to 3.1.0 did not allow `--max-size=0`.
+
+0. `--min-size=SIZE`
+
+ This tells rsync to avoid transferring any file that is smaller than the
+ specified SIZE, which can help in not transferring small, junk files. See
+ the [`--max-size`](#opt) option for a description of SIZE and other info.
+
+ Note that rsync versions prior to 3.1.0 did not allow `--min-size=0`.
+
+0. `--max-alloc=SIZE`
+
+ By default rsync limits an individual malloc/realloc to about 1GB in size.
+ For most people this limit works just fine and prevents a protocol error
+ causing rsync to request massive amounts of memory. However, if you have
+ many millions of files in a transfer, a large amount of server memory, and
+ you don't want to split up your transfer into multiple parts, you can
+ increase the per-allocation limit to something larger and rsync will
+ consume more memory.
+
+ Keep in mind that this is not a limit on the total size of allocated
+ memory. It is a sanity-check value for each individual allocation.
+
+ See the [`--max-size`](#opt) option for a description of how SIZE can be
+ specified. The default suffix if none is given is bytes.
+
+ Beginning in 3.2.3, a value of 0 specifies no limit.
+
+ You can set a default value using the environment variable
+ [`RSYNC_MAX_ALLOC`](#) using the same SIZE values as supported by this
+ option. If the remote rsync doesn't understand the `--max-alloc` option,
+ you can override an environmental value by specifying `--max-alloc=1g`,
+ which will make rsync avoid sending the option to the remote side (because
+ "1G" is the default).
+
+0. `--block-size=SIZE`, `-B`
+
+ This forces the block size used in rsync's delta-transfer algorithm to a
+ fixed value. It is normally selected based on the size of each file being
+ updated. See the technical report for details.
+
+ Beginning in 3.2.3 the SIZE can be specified with a suffix as detailed in
+ the [`--max-size`](#opt) option. Older versions only accepted a byte count.
+
+0. `--rsh=COMMAND`, `-e`
+
+ This option allows you to choose an alternative remote shell program to use
+ for communication between the local and remote copies of rsync. Typically,
+ rsync is configured to use ssh by default, but you may prefer to use rsh on
+ a local network.
+
+ If this option is used with `[user@]host::module/path`, then the remote
+ shell _COMMAND_ will be used to run an rsync daemon on the remote host, and
+ all data will be transmitted through that remote shell connection, rather
+ than through a direct socket connection to a running rsync daemon on the
+ remote host. See the [USING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL
+ CONNECTION](#) section above.
+
+ Beginning with rsync 3.2.0, the [`RSYNC_PORT`](#) environment variable will
+ be set when a daemon connection is being made via a remote-shell
+ connection. It is set to 0 if the default daemon port is being assumed, or
+ it is set to the value of the rsync port that was specified via either the
+ [`--port`](#opt) option or a non-empty port value in an `rsync://` URL.
+ This allows the script to discern if a non-default port is being requested,
+ allowing for things such as an SSL or stunnel helper script to connect to a
+ default or alternate port.
+
+ Command-line arguments are permitted in COMMAND provided that COMMAND is
+ presented to rsync as a single argument. You must use spaces (not tabs or
+ other whitespace) to separate the command and args from each other, and you
+ can use single- and/or double-quotes to preserve spaces in an argument (but
+ not backslashes). Note that doubling a single-quote inside a single-quoted
+ string gives you a single-quote; likewise for double-quotes (though you
+ need to pay attention to which quotes your shell is parsing and which
+ quotes rsync is parsing). Some examples:
+
+ > -e 'ssh -p 2234'
+ > -e 'ssh -o "ProxyCommand nohup ssh firewall nc -w1 %h %p"'
+
+ (Note that ssh users can alternately customize site-specific connect
+ options in their .ssh/config file.)
+
+ You can also choose the remote shell program using the [`RSYNC_RSH`](#)
+ environment variable, which accepts the same range of values as `-e`.
+
+ See also the [`--blocking-io`](#opt) option which is affected by this
+ option.
+
+0. `--rsync-path=PROGRAM`
+
+ Use this to specify what program is to be run on the remote machine to
+ start-up rsync. Often used when rsync is not in the default remote-shell's
+ path (e.g. `--rsync-path=/usr/local/bin/rsync`). Note that PROGRAM is run
+ with the help of a shell, so it can be any program, script, or command
+ sequence you'd care to run, so long as it does not corrupt the standard-in
+ & standard-out that rsync is using to communicate.
+
+ One tricky example is to set a different default directory on the remote
+ machine for use with the [`--relative`](#opt) option. For instance:
+
+ > rsync -avR --rsync-path="cd /a/b && rsync" host:c/d /e/
+
+0. `--remote-option=OPTION`, `-M`
+
+ This option is used for more advanced situations where you want certain
+ effects to be limited to one side of the transfer only. For instance, if
+ you want to pass [`--log-file=FILE`](#opt) and [`--fake-super`](#opt) to
+ the remote system, specify it like this:
+
+ > rsync -av -M --log-file=foo -M--fake-super src/ dest/
+
+ If you want to have an option affect only the local side of a transfer when
+ it normally affects both sides, send its negation to the remote side. Like
+ this:
+
+ > rsync -av -x -M--no-x src/ dest/
+
+ Be cautious using this, as it is possible to toggle an option that will
+ cause rsync to have a different idea about what data to expect next over
+ the socket, and that will make it fail in a cryptic fashion.
+
+ Note that you should use a separate `-M` option for each remote option you
+ want to pass. On older rsync versions, the presence of any spaces in the
+ remote-option arg could cause it to be split into separate remote args, but
+ this requires the use of [`--old-args`](#opt) in a modern rsync.
+
+ When performing a local transfer, the "local" side is the sender and the
+ "remote" side is the receiver.
+
+ Note some versions of the popt option-parsing library have a bug in them
+ that prevents you from using an adjacent arg with an equal in it next to a
+ short option letter (e.g. `-M--log-file=/tmp/foo`). If this bug affects
+ your version of popt, you can use the version of popt that is included with
+ rsync.
+
+0. `--cvs-exclude`, `-C`
+
+ This is a useful shorthand for excluding a broad range of files that you
+ often don't want to transfer between systems. It uses a similar algorithm
+ to CVS to determine if a file should be ignored.
+
+ The exclude list is initialized to exclude the following items (these
+ initial items are marked as perishable -- see the [FILTER RULES](#)
+ section):
+
+ [comment]: # (This list gets used for the default-cvsignore.h file.)
+
+ > `RCS`
+ > `SCCS`
+ > `CVS`
+ > `CVS.adm`
+ > `RCSLOG`
+ > `cvslog.*`
+ > `tags`
+ > `TAGS`
+ > `.make.state`
+ > `.nse_depinfo`
+ > `*~`
+ > `#*`
+ > `.#*`
+ > `,*`
+ > `_$*`
+ > `*$`
+ > `*.old`
+ > `*.bak`
+ > `*.BAK`
+ > `*.orig`
+ > `*.rej`
+ > `.del-*`
+ > `*.a`
+ > `*.olb`
+ > `*.o`
+ > `*.obj`
+ > `*.so`
+ > `*.exe`
+ > `*.Z`
+ > `*.elc`
+ > `*.ln`
+ > `core`
+ > `.svn/`
+ > `.git/`
+ > `.hg/`
+ > `.bzr/`
+
+ then, files listed in a $HOME/.cvsignore are added to the list and any
+ files listed in the CVSIGNORE environment variable (all cvsignore names are
+ delimited by whitespace).
+
+ Finally, any file is ignored if it is in the same directory as a .cvsignore
+ file and matches one of the patterns listed therein. Unlike rsync's
+ filter/exclude files, these patterns are split on whitespace. See the
+ **cvs**(1) manual for more information.
+
+ If you're combining `-C` with your own [`--filter`](#opt) rules, you should
+ note that these CVS excludes are appended at the end of your own rules,
+ regardless of where the `-C` was placed on the command-line. This makes
+ them a lower priority than any rules you specified explicitly. If you want
+ to control where these CVS excludes get inserted into your filter rules,
+ you should omit the `-C` as a command-line option and use a combination of
+ [`--filter=:C`](#opt) and [`--filter=-C`](#opt) (either on your
+ command-line or by putting the ":C" and "-C" rules into a filter file with
+ your other rules). The first option turns on the per-directory scanning
+ for the .cvsignore file. The second option does a one-time import of the
+ CVS excludes mentioned above.
+
+0. `--filter=RULE`, `-f`
+
+ This option allows you to add rules to selectively exclude certain files
+ from the list of files to be transferred. This is most useful in
+ combination with a recursive transfer.
+
+ You may use as many `--filter` options on the command line as you like to
+ build up the list of files to exclude. If the filter contains whitespace,
+ be sure to quote it so that the shell gives the rule to rsync as a single
+ argument. The text below also mentions that you can use an underscore to
+ replace the space that separates a rule from its arg.
+
+ See the [FILTER RULES](#) section for detailed information on this option.
+
+0. `-F`
+
+ The `-F` option is a shorthand for adding two [`--filter`](#opt) rules to
+ your command. The first time it is used is a shorthand for this rule:
+
+ > --filter='dir-merge /.rsync-filter'
+
+ This tells rsync to look for per-directory .rsync-filter files that have
+ been sprinkled through the hierarchy and use their rules to filter the
+ files in the transfer. If `-F` is repeated, it is a shorthand for this
+ rule:
+
+ > --filter='exclude .rsync-filter'
+
+ This filters out the .rsync-filter files themselves from the transfer.
+
+ See the [FILTER RULES](#) section for detailed information on how these
+ options work.
+
+0. `--exclude=PATTERN`
+
+ This option is a simplified form of the [`--filter`](#opt) option that
+ specifies an exclude rule and does not allow the full rule-parsing syntax
+ of normal filter rules. This is equivalent to specifying `-f'- PATTERN'`.
+
+ See the [FILTER RULES](#) section for detailed information on this option.
+
+0. `--exclude-from=FILE`
+
+ This option is related to the [`--exclude`](#opt) option, but it specifies
+ a FILE that contains exclude patterns (one per line). Blank lines in the
+ file are ignored, as are whole-line comments that start with '`;`' or '`#`'
+ (filename rules that contain those characters are unaffected).
+
+ If a line begins with "`- `" (dash, space) or "`+ `" (plus, space), then
+ the type of rule is being explicitly specified as an exclude or an include
+ (respectively). Any rules without such a prefix are taken to be an exclude.
+
+ If a line consists of just "`!`", then the current filter rules are cleared
+ before adding any further rules.
+
+ If _FILE_ is '`-`', the list will be read from standard input.
+
+0. `--include=PATTERN`
+
+ This option is a simplified form of the [`--filter`](#opt) option that
+ specifies an include rule and does not allow the full rule-parsing syntax
+ of normal filter rules. This is equivalent to specifying `-f'+ PATTERN'`.
+
+ See the [FILTER RULES](#) section for detailed information on this option.
+
+0. `--include-from=FILE`
+
+ This option is related to the [`--include`](#opt) option, but it specifies
+ a FILE that contains include patterns (one per line). Blank lines in the
+ file are ignored, as are whole-line comments that start with '`;`' or '`#`'
+ (filename rules that contain those characters are unaffected).
+
+ If a line begins with "`- `" (dash, space) or "`+ `" (plus, space), then
+ the type of rule is being explicitly specified as an exclude or an include
+ (respectively). Any rules without such a prefix are taken to be an include.
+
+ If a line consists of just "`!`", then the current filter rules are cleared
+ before adding any further rules.
+
+ If _FILE_ is '`-`', the list will be read from standard input.
+
+0. `--files-from=FILE`
+
+ Using this option allows you to specify the exact list of files to transfer
+ (as read from the specified FILE or '`-`' for standard input). It also
+ tweaks the default behavior of rsync to make transferring just the
+ specified files and directories easier:
+
+ - The [`--relative`](#opt) (`-R`) option is implied, which preserves the
+ path information that is specified for each item in the file (use
+ `--no-relative` or `--no-R` if you want to turn that off).
+ - The [`--dirs`](#opt) (`-d`) option is implied, which will create
+ directories specified in the list on the destination rather than noisily
+ skipping them (use `--no-dirs` or `--no-d` if you want to turn that off).
+ - The [`--archive`](#opt) (`-a`) option's behavior does not imply
+ [`--recursive`](#opt) (`-r`), so specify it explicitly, if you want it.
+ - These side-effects change the default state of rsync, so the position of
+ the `--files-from` option on the command-line has no bearing on how other
+ options are parsed (e.g. [`-a`](#opt) works the same before or after
+ `--files-from`, as does `--no-R` and all other options).
+
+ The filenames that are read from the FILE are all relative to the source
+ dir -- any leading slashes are removed and no ".." references are allowed
+ to go higher than the source dir. For example, take this command:
+
+ > rsync -a --files-from=/tmp/foo /usr remote:/backup
+
+ If /tmp/foo contains the string "bin" (or even "/bin"), the /usr/bin
+ directory will be created as /backup/bin on the remote host. If it
+ contains "bin/" (note the trailing slash), the immediate contents of the
+ directory would also be sent (without needing to be explicitly mentioned in
+ the file -- this began in version 2.6.4). In both cases, if the
+ [`-r`](#opt) option was enabled, that dir's entire hierarchy would also be
+ transferred (keep in mind that [`-r`](#opt) needs to be specified
+ explicitly with `--files-from`, since it is not implied by [`-a`](#opt).
+ Also note that the effect of the (enabled by default) [`-r`](#opt) option
+ is to duplicate only the path info that is read from the file -- it does
+ not force the duplication of the source-spec path (/usr in this case).
+
+ In addition, the `--files-from` file can be read from the remote host
+ instead of the local host if you specify a "host:" in front of the file
+ (the host must match one end of the transfer). As a short-cut, you can
+ specify just a prefix of ":" to mean "use the remote end of the transfer".
+ For example:
+
+ > rsync -a --files-from=:/path/file-list src:/ /tmp/copy
+
+ This would copy all the files specified in the /path/file-list file that
+ was located on the remote "src" host.
+
+ If the [`--iconv`](#opt) and [`--secluded-args`](#opt) options are specified
+ and the `--files-from` filenames are being sent from one host to another,
+ the filenames will be translated from the sending host's charset to the
+ receiving host's charset.
+
+ NOTE: sorting the list of files in the `--files-from` input helps rsync to
+ be more efficient, as it will avoid re-visiting the path elements that are
+ shared between adjacent entries. If the input is not sorted, some path
+ elements (implied directories) may end up being scanned multiple times, and
+ rsync will eventually unduplicate them after they get turned into file-list
+ elements.
+
+0. `--from0`, `-0`
+
+ This tells rsync that the rules/filenames it reads from a file are
+ terminated by a null ('\\0') character, not a NL, CR, or CR+LF. This
+ affects [`--exclude-from`](#opt), [`--include-from`](#opt),
+ [`--files-from`](#opt), and any merged files specified in a
+ [`--filter`](#opt) rule. It does not affect [`--cvs-exclude`](#opt) (since
+ all names read from a .cvsignore file are split on whitespace).
+
+0. `--old-args`
+
+ This option tells rsync to stop trying to protect the arg values on the
+ remote side from unintended word-splitting or other misinterpretation.
+ It also allows the client to treat an empty arg as a "." instead of
+ generating an error.
+
+ The default in a modern rsync is for "shell-active" characters (including
+ spaces) to be backslash-escaped in the args that are sent to the remote
+ shell. The wildcard characters `*`, `?`, `[`, & `]` are not escaped in
+ filename args (allowing them to expand into multiple filenames) while being
+ protected in option args, such as [`--usermap`](#opt).
+
+ If you have a script that wants to use old-style arg splitting in its
+ filenames, specify this option once. If the remote shell has a problem
+ with any backslash escapes at all, specify this option twice.
+
+ You may also control this setting via the [`RSYNC_OLD_ARGS`](#) environment
+ variable. If it has the value "1", rsync will default to a single-option
+ setting. If it has the value "2" (or more), rsync will default to a
+ repeated-option setting. If it is "0", you'll get the default escaping
+ behavior. The environment is always overridden by manually specified
+ positive or negative options (the negative is `--no-old-args`).
+
+ Note that this option also disables the extra safety check added in 3.2.5
+ that ensures that a remote sender isn't including extra top-level items in
+ the file-list that you didn't request. This side-effect is necessary
+ because we can't know for sure what names to expect when the remote shell
+ is interpreting the args.
+
+ This option conflicts with the [`--secluded-args`](#opt) option.
+
+0. `--secluded-args`, `-s`
+
+ This option sends all filenames and most options to the remote rsync via
+ the protocol (not the remote shell command line) which avoids letting the
+ remote shell modify them. Wildcards are expanded on the remote host by
+ rsync instead of a shell.
+
+ This is similar to the default backslash-escaping of args that was added
+ in 3.2.4 (see [`--old-args`](#opt)) in that it prevents things like space
+ splitting and unwanted special-character side-effects. However, it has the
+ drawbacks of being incompatible with older rsync versions (prior to 3.0.0)
+ and of being refused by restricted shells that want to be able to inspect
+ all the option values for safety.
+
+ This option is useful for those times that you need the argument's
+ character set to be converted for the remote host, if the remote shell is
+ incompatible with the default backslash-escpaing method, or there is some
+ other reason that you want the majority of the options and arguments to
+ bypass the command-line of the remote shell.
+
+ If you combine this option with [`--iconv`](#opt), the args related to the
+ remote side will be translated from the local to the remote character-set.
+ The translation happens before wild-cards are expanded. See also the
+ [`--files-from`](#opt) option.
+
+ You may also control this setting via the [`RSYNC_PROTECT_ARGS`](#)
+ environment variable. If it has a non-zero value, this setting will be
+ enabled by default, otherwise it will be disabled by default. Either state
+ is overridden by a manually specified positive or negative version of this
+ option (note that `--no-s` and `--no-secluded-args` are the negative
+ versions). This environment variable is also superseded by a non-zero
+ [`RSYNC_OLD_ARGS`](#) export.
+
+ This option conflicts with the [`--old-args`](#opt) option.
+
+ This option used to be called `--protect-args` (before 3.2.6) and that
+ older name can still be used (though specifying it as `-s` is always the
+ easiest and most compatible choice).
+
+0. `--trust-sender`
+
+ This option disables two extra validation checks that a local client
+ performs on the file list generated by a remote sender. This option should
+ only be used if you trust the sender to not put something malicious in the
+ file list (something that could possibly be done via a modified rsync, a
+ modified shell, or some other similar manipulation).
+
+ Normally, the rsync client (as of version 3.2.5) runs two extra validation
+ checks when pulling files from a remote rsync:
+
+ - It verifies that additional arg items didn't get added at the top of the
+ transfer.
+ - It verifies that none of the items in the file list are names that should
+ have been excluded (if filter rules were specified).
+
+ Note that various options can turn off one or both of these checks if the
+ option interferes with the validation. For instance:
+
+ - Using a per-directory filter file reads filter rules that only the server
+ knows about, so the filter checking is disabled.
+ - Using the [`--old-args`](#opt) option allows the sender to manipulate the
+ requested args, so the arg checking is disabled.
+ - Reading the files-from list from the server side means that the client
+ doesn't know the arg list, so the arg checking is disabled.
+ - Using [`--read-batch`](#opt) disables both checks since the batch file's
+ contents will have been verified when it was created.
+
+ This option may help an under-powered client server if the extra pattern
+ matching is slowing things down on a huge transfer. It can also be used to
+ work around a currently-unknown bug in the verification logic for a transfer
+ from a trusted sender.
+
+ When using this option it is a good idea to specify a dedicated destination
+ directory, as discussed in the [MULTI-HOST SECURITY](#) section.
+
+0. `--copy-as=USER[:GROUP]`
+
+ This option instructs rsync to use the USER and (if specified after a
+ colon) the GROUP for the copy operations. This only works if the user that
+ is running rsync has the ability to change users. If the group is not
+ specified then the user's default groups are used.
+
+ This option can help to reduce the risk of an rsync being run as root into
+ or out of a directory that might have live changes happening to it and you
+ want to make sure that root-level read or write actions of system files are
+ not possible. While you could alternatively run all of rsync as the
+ specified user, sometimes you need the root-level host-access credentials
+ to be used, so this allows rsync to drop root for the copying part of the
+ operation after the remote-shell or daemon connection is established.
+
+ The option only affects one side of the transfer unless the transfer is
+ local, in which case it affects both sides. Use the
+ [`--remote-option`](#opt) to affect the remote side, such as
+ `-M--copy-as=joe`. For a local transfer, the lsh (or lsh.sh) support file
+ provides a local-shell helper script that can be used to allow a
+ "localhost:" or "lh:" host-spec to be specified without needing to setup
+ any remote shells, allowing you to specify remote options that affect the
+ side of the transfer that is using the host-spec (and using hostname "lh"
+ avoids the overriding of the remote directory to the user's home dir).
+
+ For example, the following rsync writes the local files as user "joe":
+
+ > sudo rsync -aiv --copy-as=joe host1:backups/joe/ /home/joe/
+
+ This makes all files owned by user "joe", limits the groups to those that
+ are available to that user, and makes it impossible for the joe user to do
+ a timed exploit of the path to induce a change to a file that the joe user
+ has no permissions to change.
+
+ The following command does a local copy into the "dest/" dir as user "joe"
+ (assuming you've installed support/lsh into a dir on your $PATH):
+
+ > sudo rsync -aive lsh -M--copy-as=joe src/ lh:dest/
+
+0. `--temp-dir=DIR`, `-T`
+
+ This option instructs rsync to use DIR as a scratch directory when creating
+ temporary copies of the files transferred on the receiving side. The
+ default behavior is to create each temporary file in the same directory as
+ the associated destination file. Beginning with rsync 3.1.1, the temp-file
+ names inside the specified DIR will not be prefixed with an extra dot
+ (though they will still have a random suffix added).
+
+ This option is most often used when the receiving disk partition does not
+ have enough free space to hold a copy of the largest file in the transfer.
+ In this case (i.e. when the scratch directory is on a different disk
+ partition), rsync will not be able to rename each received temporary file
+ over the top of the associated destination file, but instead must copy it
+ into place. Rsync does this by copying the file over the top of the
+ destination file, which means that the destination file will contain
+ truncated data during this copy. If this were not done this way (even if
+ the destination file were first removed, the data locally copied to a
+ temporary file in the destination directory, and then renamed into place)
+ it would be possible for the old file to continue taking up disk space (if
+ someone had it open), and thus there might not be enough room to fit the
+ new version on the disk at the same time.
+
+ If you are using this option for reasons other than a shortage of disk
+ space, you may wish to combine it with the [`--delay-updates`](#opt)
+ option, which will ensure that all copied files get put into subdirectories
+ in the destination hierarchy, awaiting the end of the transfer. If you
+ don't have enough room to duplicate all the arriving files on the
+ destination partition, another way to tell rsync that you aren't overly
+ concerned about disk space is to use the [`--partial-dir`](#opt) option
+ with a relative path; because this tells rsync that it is OK to stash off a
+ copy of a single file in a subdir in the destination hierarchy, rsync will
+ use the partial-dir as a staging area to bring over the copied file, and
+ then rename it into place from there. (Specifying a [`--partial-dir`](#opt)
+ with an absolute path does not have this side-effect.)
+
+0. `--fuzzy`, `-y`
+
+ This option tells rsync that it should look for a basis file for any
+ destination file that is missing. The current algorithm looks in the same
+ directory as the destination file for either a file that has an identical
+ size and modified-time, or a similarly-named file. If found, rsync uses
+ the fuzzy basis file to try to speed up the transfer.
+
+ If the option is repeated, the fuzzy scan will also be done in any matching
+ alternate destination directories that are specified via
+ [`--compare-dest`](#opt), [`--copy-dest`](#opt), or [`--link-dest`](#opt).
+
+ Note that the use of the [`--delete`](#opt) option might get rid of any
+ potential fuzzy-match files, so either use [`--delete-after`](#opt) or
+ specify some filename exclusions if you need to prevent this.
+
+0. `--compare-dest=DIR`
+
+ This option instructs rsync to use _DIR_ on the destination machine as an
+ additional hierarchy to compare destination files against doing transfers
+ (if the files are missing in the destination directory). If a file is
+ found in _DIR_ that is identical to the sender's file, the file will NOT be
+ transferred to the destination directory. This is useful for creating a
+ sparse backup of just files that have changed from an earlier backup. This
+ option is typically used to copy into an empty (or newly created)
+ directory.
+
+ Beginning in version 2.6.4, multiple `--compare-dest` directories may be
+ provided, which will cause rsync to search the list in the order specified
+ for an exact match. If a match is found that differs only in attributes, a
+ local copy is made and the attributes updated. If a match is not found, a
+ basis file from one of the _DIRs_ will be selected to try to speed up the
+ transfer.
+
+ If _DIR_ is a relative path, it is relative to the destination directory.
+ See also [`--copy-dest`](#opt) and [`--link-dest`](#opt).
+
+ NOTE: beginning with version 3.1.0, rsync will remove a file from a
+ non-empty destination hierarchy if an exact match is found in one of the
+ compare-dest hierarchies (making the end result more closely match a fresh
+ copy).
+
+0. `--copy-dest=DIR`
+
+ This option behaves like [`--compare-dest`](#opt), but rsync will also copy
+ unchanged files found in _DIR_ to the destination directory using a local
+ copy. This is useful for doing transfers to a new destination while
+ leaving existing files intact, and then doing a flash-cutover when all
+ files have been successfully transferred.
+
+ Multiple `--copy-dest` directories may be provided, which will cause rsync
+ to search the list in the order specified for an unchanged file. If a
+ match is not found, a basis file from one of the _DIRs_ will be selected to
+ try to speed up the transfer.
+
+ If _DIR_ is a relative path, it is relative to the destination directory.
+ See also [`--compare-dest`](#opt) and [`--link-dest`](#opt).
+
+0. `--link-dest=DIR`
+
+ This option behaves like [`--copy-dest`](#opt), but unchanged files are
+ hard linked from _DIR_ to the destination directory. The files must be
+ identical in all preserved attributes (e.g. permissions, possibly
+ ownership) in order for the files to be linked together. An example:
+
+ > rsync -av --link-dest=$PWD/prior_dir host:src_dir/ new_dir/
+
+ If files aren't linking, double-check their attributes. Also check if
+ some attributes are getting forced outside of rsync's control, such a mount
+ option that squishes root to a single user, or mounts a removable drive
+ with generic ownership (such as OS X's "Ignore ownership on this volume"
+ option).
+
+ Beginning in version 2.6.4, multiple `--link-dest` directories may be
+ provided, which will cause rsync to search the list in the order specified
+ for an exact match (there is a limit of 20 such directories). If a match
+ is found that differs only in attributes, a local copy is made and the
+ attributes updated. If a match is not found, a basis file from one of the
+ _DIRs_ will be selected to try to speed up the transfer.
+
+ This option works best when copying into an empty destination hierarchy, as
+ existing files may get their attributes tweaked, and that can affect
+ alternate destination files via hard-links. Also, itemizing of changes can
+ get a bit muddled. Note that prior to version 3.1.0, an
+ alternate-directory exact match would never be found (nor linked into the
+ destination) when a destination file already exists.
+
+ Note that if you combine this option with [`--ignore-times`](#opt), rsync will not
+ link any files together because it only links identical files together as a
+ substitute for transferring the file, never as an additional check after
+ the file is updated.
+
+ If _DIR_ is a relative path, it is relative to the destination directory.
+ See also [`--compare-dest`](#opt) and [`--copy-dest`](#opt).
+
+ Note that rsync versions prior to 2.6.1 had a bug that could prevent
+ `--link-dest` from working properly for a non-super-user when
+ [`--owner`](#opt) (`-o`) was specified (or implied). You can work-around
+ this bug by avoiding the `-o` option (or using `--no-o`) when sending to an
+ old rsync.
+
+0. `--compress`, `-z`
+
+ With this option, rsync compresses the file data as it is sent to the
+ destination machine, which reduces the amount of data being transmitted --
+ something that is useful over a slow connection.
+
+ Rsync supports multiple compression methods and will choose one for you
+ unless you force the choice using the [`--compress-choice`](#opt) (`--zc`)
+ option.
+
+ Run `rsync --version` to see the default compress list compiled into your
+ version.
+
+ When both sides of the transfer are at least 3.2.0, rsync chooses the first
+ algorithm in the client's list of choices that is also in the server's list
+ of choices. If no common compress choice is found, rsync exits with
+ an error. If the remote rsync is too old to support checksum negotiation,
+ its list is assumed to be "zlib".
+
+ The default order can be customized by setting the environment variable
+ [`RSYNC_COMPRESS_LIST`](#) to a space-separated list of acceptable
+ compression names. If the string contains a "`&`" character, it is
+ separated into the "client string & server string", otherwise the same
+ string applies to both. If the string (or string portion) contains no
+ non-whitespace characters, the default compress list is used. Any unknown
+ compression names are discarded from the list, but a list with only invalid
+ names results in a failed negotiation.
+
+ There are some older rsync versions that were configured to reject a `-z`
+ option and require the use of `-zz` because their compression library was
+ not compatible with the default zlib compression method. You can usually
+ ignore this weirdness unless the rsync server complains and tells you to
+ specify `-zz`.
+
+0. `--compress-choice=STR`, `--zc=STR`
+
+ This option can be used to override the automatic negotiation of the
+ compression algorithm that occurs when [`--compress`](#opt) is used. The
+ option implies [`--compress`](#opt) unless "none" was specified, which
+ instead implies `--no-compress`.
+
+ The compression options that you may be able to use are:
+
+ - `zstd`
+ - `lz4`
+ - `zlibx`
+ - `zlib`
+ - `none`
+
+ Run `rsync --version` to see the default compress list compiled into your
+ version (which may differ from the list above).
+
+ Note that if you see an error about an option named `--old-compress` or
+ `--new-compress`, this is rsync trying to send the `--compress-choice=zlib`
+ or `--compress-choice=zlibx` option in a backward-compatible manner that
+ more rsync versions understand. This error indicates that the older rsync
+ version on the server will not allow you to force the compression type.
+
+ Note that the "zlibx" compression algorithm is just the "zlib" algorithm
+ with matched data excluded from the compression stream (to try to make it
+ more compatible with an external zlib implementation).
+
+0. `--compress-level=NUM`, `--zl=NUM`
+
+ Explicitly set the compression level to use (see [`--compress`](#opt),
+ `-z`) instead of letting it default. The [`--compress`](#opt) option is
+ implied as long as the level chosen is not a "don't compress" level for the
+ compression algorithm that is in effect (e.g. zlib compression treats level
+ 0 as "off").
+
+ The level values vary depending on the checksum in effect. Because rsync
+ will negotiate a checksum choice by default (when the remote rsync is new
+ enough), it can be good to combine this option with a
+ [`--compress-choice`](#opt) (`--zc`) option unless you're sure of the
+ choice in effect. For example:
+
+ > rsync -aiv --zc=zstd --zl=22 host:src/ dest/
+
+ For zlib & zlibx compression the valid values are from 1 to 9 with 6 being
+ the default. Specifying `--zl=0` turns compression off, and specifying
+ `--zl=-1` chooses the default level of 6.
+
+ For zstd compression the valid values are from -131072 to 22 with 3 being
+ the default. Specifying 0 chooses the default of 3.
+
+ For lz4 compression there are no levels, so the value is always 0.
+
+ If you specify a too-large or too-small value, the number is silently
+ limited to a valid value. This allows you to specify something like
+ `--zl=999999999` and be assured that you'll end up with the maximum
+ compression level no matter what algorithm was chosen.
+
+ If you want to know the compression level that is in effect, specify
+ [`--debug=nstr`](#opt) to see the "negotiated string" results. This will
+ report something like "`Client compress: zstd (level 3)`" (along with the
+ checksum choice in effect).
+
+0. `--skip-compress=LIST`
+
+ **NOTE:** no compression method currently supports per-file compression
+ changes, so this option has no effect.
+
+ Override the list of file suffixes that will be compressed as little as
+ possible. Rsync sets the compression level on a per-file basis based on
+ the file's suffix. If the compression algorithm has an "off" level, then
+ no compression occurs for those files. Other algorithms that support
+ changing the streaming level on-the-fly will have the level minimized to
+ reduces the CPU usage as much as possible for a matching file.
+
+ The **LIST** should be one or more file suffixes (without the dot) separated
+ by slashes (`/`). You may specify an empty string to indicate that no files
+ should be skipped.
+
+ Simple character-class matching is supported: each must consist of a list
+ of letters inside the square brackets (e.g. no special classes, such as
+ "[:alpha:]", are supported, and '-' has no special meaning).
+
+ The characters asterisk (`*`) and question-mark (`?`) have no special meaning.
+
+ Here's an example that specifies 6 suffixes to skip (since 1 of the 5 rules
+ matches 2 suffixes):
+
+ > --skip-compress=gz/jpg/mp[34]/7z/bz2
+
+ The default file suffixes in the skip-compress list in this version of
+ rsync are:
+
+ [comment]: # (This list gets used for the default-dont-compress.h file.)
+
+ > 3g2
+ > 3gp
+ > 7z
+ > aac
+ > ace
+ > apk
+ > avi
+ > bz2
+ > deb
+ > dmg
+ > ear
+ > f4v
+ > flac
+ > flv
+ > gpg
+ > gz
+ > iso
+ > jar
+ > jpeg
+ > jpg
+ > lrz
+ > lz
+ > lz4
+ > lzma
+ > lzo
+ > m1a
+ > m1v
+ > m2a
+ > m2ts
+ > m2v
+ > m4a
+ > m4b
+ > m4p
+ > m4r
+ > m4v
+ > mka
+ > mkv
+ > mov
+ > mp1
+ > mp2
+ > mp3
+ > mp4
+ > mpa
+ > mpeg
+ > mpg
+ > mpv
+ > mts
+ > odb
+ > odf
+ > odg
+ > odi
+ > odm
+ > odp
+ > ods
+ > odt
+ > oga
+ > ogg
+ > ogm
+ > ogv
+ > ogx
+ > opus
+ > otg
+ > oth
+ > otp
+ > ots
+ > ott
+ > oxt
+ > png
+ > qt
+ > rar
+ > rpm
+ > rz
+ > rzip
+ > spx
+ > squashfs
+ > sxc
+ > sxd
+ > sxg
+ > sxm
+ > sxw
+ > sz
+ > tbz
+ > tbz2
+ > tgz
+ > tlz
+ > ts
+ > txz
+ > tzo
+ > vob
+ > war
+ > webm
+ > webp
+ > xz
+ > z
+ > zip
+ > zst
+
+ This list will be replaced by your `--skip-compress` list in all but one
+ situation: a copy from a daemon rsync will add your skipped suffixes to its
+ list of non-compressing files (and its list may be configured to a
+ different default).
+
+0. `--numeric-ids`
+
+ With this option rsync will transfer numeric group and user IDs rather than
+ using user and group names and mapping them at both ends.
+
+ By default rsync will use the username and groupname to determine what
+ ownership to give files. The special uid 0 and the special group 0 are
+ never mapped via user/group names even if the `--numeric-ids` option is not
+ specified.
+
+ If a user or group has no name on the source system or it has no match on
+ the destination system, then the numeric ID from the source system is used
+ instead. See also the [`use chroot`](rsyncd.conf.5#use_chroot) setting
+ in the rsyncd.conf manpage for some comments on how the chroot setting
+ affects rsync's ability to look up the names of the users and groups and
+ what you can do about it.
+
+0. `--usermap=STRING`, `--groupmap=STRING`
+
+ These options allow you to specify users and groups that should be mapped
+ to other values by the receiving side. The **STRING** is one or more
+ **FROM**:**TO** pairs of values separated by commas. Any matching **FROM**
+ value from the sender is replaced with a **TO** value from the receiver.
+ You may specify usernames or user IDs for the **FROM** and **TO** values,
+ and the **FROM** value may also be a wild-card string, which will be
+ matched against the sender's names (wild-cards do NOT match against ID
+ numbers, though see below for why a '`*`' matches everything). You may
+ instead specify a range of ID numbers via an inclusive range: LOW-HIGH.
+ For example:
+
+ > --usermap=0-99:nobody,wayne:admin,*:normal --groupmap=usr:1,1:usr
+
+ The first match in the list is the one that is used. You should specify
+ all your user mappings using a single `--usermap` option, and/or all your
+ group mappings using a single `--groupmap` option.
+
+ Note that the sender's name for the 0 user and group are not transmitted to
+ the receiver, so you should either match these values using a 0, or use the
+ names in effect on the receiving side (typically "root"). All other
+ **FROM** names match those in use on the sending side. All **TO** names
+ match those in use on the receiving side.
+
+ Any IDs that do not have a name on the sending side are treated as having
+ an empty name for the purpose of matching. This allows them to be matched
+ via a "`*`" or using an empty name. For instance:
+
+ > --usermap=:nobody --groupmap=*:nobody
+
+ When the [`--numeric-ids`](#opt) option is used, the sender does not send any
+ names, so all the IDs are treated as having an empty name. This means that
+ you will need to specify numeric **FROM** values if you want to map these
+ nameless IDs to different values.
+
+ For the `--usermap` option to work, the receiver will need to be running as
+ a super-user (see also the [`--super`](#opt) and [`--fake-super`](#opt)
+ options). For the `--groupmap` option to work, the receiver will need to
+ have permissions to set that group.
+
+ Starting with rsync 3.2.4, the `--usermap` option implies the
+ [`--owner`](#opt) (`-o`) option while the `--groupmap` option implies the
+ [`--group`](#opt) (`-g`) option (since rsync needs to have those options
+ enabled for the mapping options to work).
+
+ An older rsync client may need to use [`-s`](#opt) to avoid a complaint
+ about wildcard characters, but a modern rsync handles this automatically.
+
+0. `--chown=USER:GROUP`
+
+ This option forces all files to be owned by USER with group GROUP. This is
+ a simpler interface than using [`--usermap`](#opt) & [`--groupmap`](#opt)
+ directly, but it is implemented using those options internally so they
+ cannot be mixed. If either the USER or GROUP is empty, no mapping for the
+ omitted user/group will occur. If GROUP is empty, the trailing colon may
+ be omitted, but if USER is empty, a leading colon must be supplied.
+
+ If you specify "`--chown=foo:bar`", this is exactly the same as specifying
+ "`--usermap=*:foo --groupmap=*:bar`", only easier (and with the same
+ implied [`--owner`](#opt) and/or [`--group`](#opt) options).
+
+ An older rsync client may need to use [`-s`](#opt) to avoid a complaint
+ about wildcard characters, but a modern rsync handles this automatically.
+
+0. `--timeout=SECONDS`
+
+ This option allows you to set a maximum I/O timeout in seconds. If no data
+ is transferred for the specified time then rsync will exit. The default is
+ 0, which means no timeout.
+
+0. `--contimeout=SECONDS`
+
+ This option allows you to set the amount of time that rsync will wait for
+ its connection to an rsync daemon to succeed. If the timeout is reached,
+ rsync exits with an error.
+
+0. `--address=ADDRESS`
+
+ By default rsync will bind to the wildcard address when connecting to an
+ rsync daemon. The `--address` option allows you to specify a specific IP
+ address (or hostname) to bind to.
+
+ See also [the daemon version of the `--address` option](#dopt--address).
+
+0. `--port=PORT`
+
+ This specifies an alternate TCP port number to use rather than the default
+ of 873. This is only needed if you are using the double-colon (::) syntax
+ to connect with an rsync daemon (since the URL syntax has a way to specify
+ the port as a part of the URL).
+
+ See also [the daemon version of the `--port` option](#dopt--port).
+
+0. `--sockopts=OPTIONS`
+
+ This option can provide endless fun for people who like to tune their
+ systems to the utmost degree. You can set all sorts of socket options
+ which may make transfers faster (or slower!). Read the manpage for the
+ `setsockopt()` system call for details on some of the options you may be
+ able to set. By default no special socket options are set. This only
+ affects direct socket connections to a remote rsync daemon.
+
+ See also [the daemon version of the `--sockopts` option](#dopt--sockopts).
+
+0. `--blocking-io`
+
+ This tells rsync to use blocking I/O when launching a remote shell
+ transport. If the remote shell is either rsh or remsh, rsync defaults to
+ using blocking I/O, otherwise it defaults to using non-blocking I/O. (Note
+ that ssh prefers non-blocking I/O.)
+
+0. `--outbuf=MODE`
+
+ This sets the output buffering mode. The mode can be None (aka
+ Unbuffered), Line, or Block (aka Full). You may specify as little as a
+ single letter for the mode, and use upper or lower case.
+
+ The main use of this option is to change Full buffering to Line buffering
+ when rsync's output is going to a file or pipe.
+
+0. `--itemize-changes`, `-i`
+
+ Requests a simple itemized list of the changes that are being made to each
+ file, including attribute changes. This is exactly the same as specifying
+ [`--out-format='%i %n%L'`](#opt). If you repeat the option, unchanged
+ files will also be output, but only if the receiving rsync is at least
+ version 2.6.7 (you can use `-vv` with older versions of rsync, but that
+ also turns on the output of other verbose messages).
+
+ The "%i" escape has a cryptic output that is 11 letters long. The general
+ format is like the string `YXcstpoguax`, where **Y** is replaced by the type
+ of update being done, **X** is replaced by the file-type, and the other
+ letters represent attributes that may be output if they are being modified.
+
+ The update types that replace the **Y** are as follows:
+
+ - A `<` means that a file is being transferred to the remote host (sent).
+ - A `>` means that a file is being transferred to the local host
+ (received).
+ - A `c` means that a local change/creation is occurring for the item (such
+ as the creation of a directory or the changing of a symlink, etc.).
+ - A `h` means that the item is a hard link to another item (requires
+ [`--hard-links`](#opt)).
+ - A `.` means that the item is not being updated (though it might have
+ attributes that are being modified).
+ - A `*` means that the rest of the itemized-output area contains a message
+ (e.g. "deleting").
+
+ The file-types that replace the **X** are: `f` for a file, a `d` for a
+ directory, an `L` for a symlink, a `D` for a device, and a `S` for a
+ special file (e.g. named sockets and fifos).
+
+ The other letters in the string indicate if some attributes of the file
+ have changed, as follows:
+
+ - "`.`" - the attribute is unchanged.
+ - "`+`" - the file is newly created.
+ - "` `" - all the attributes are unchanged (all dots turn to spaces).
+ - "`?`" - the change is unknown (when the remote rsync is old).
+ - A letter indicates an attribute is being updated.
+
+ The attribute that is associated with each letter is as follows:
+
+ - A `c` means either that a regular file has a different checksum (requires
+ [`--checksum`](#opt)) or that a symlink, device, or special file has a
+ changed value. Note that if you are sending files to an rsync prior to
+ 3.0.1, this change flag will be present only for checksum-differing
+ regular files.
+ - A `s` means the size of a regular file is different and will be updated
+ by the file transfer.
+ - A `t` means the modification time is different and is being updated to
+ the sender's value (requires [`--times`](#opt)). An alternate value of
+ `T` means that the modification time will be set to the transfer time,
+ which happens when a file/symlink/device is updated without
+ [`--times`](#opt) and when a symlink is changed and the receiver can't
+ set its time. (Note: when using an rsync 3.0.0 client, you might see the
+ `s` flag combined with `t` instead of the proper `T` flag for this
+ time-setting failure.)
+ - A `p` means the permissions are different and are being updated to the
+ sender's value (requires [`--perms`](#opt)).
+ - An `o` means the owner is different and is being updated to the sender's
+ value (requires [`--owner`](#opt) and super-user privileges).
+ - A `g` means the group is different and is being updated to the sender's
+ value (requires [`--group`](#opt) and the authority to set the group).
+ - A `u`|`n`|`b` indicates the following information:
+ - `u` means the access (use) time is different and is being updated to
+ the sender's value (requires [`--atimes`](#opt))
+ - `n` means the create time (newness) is different and is being updated
+ to the sender's value (requires [`--crtimes`](#opt))
+ - `b` means that both the access and create times are being updated
+ - The `a` means that the ACL information is being changed.
+ - The `x` means that the extended attribute information is being changed.
+
+ One other output is possible: when deleting files, the "%i" will output the
+ string "`*deleting`" for each item that is being removed (assuming that you
+ are talking to a recent enough rsync that it logs deletions instead of
+ outputting them as a verbose message).
+
+0. `--out-format=FORMAT`
+
+ This allows you to specify exactly what the rsync client outputs to the
+ user on a per-update basis. The format is a text string containing
+ embedded single-character escape sequences prefixed with a percent (%)
+ character. A default format of "%n%L" is assumed if either
+ [`--info=name`](#opt) or [`-v`](#opt) is specified (this tells you just the
+ name of the file and, if the item is a link, where it points). For a full
+ list of the possible escape characters, see the [`log
+ format`](rsyncd.conf.5#log_format) setting in the rsyncd.conf manpage.
+
+ Specifying the `--out-format` option implies the [`--info=name`](#opt)
+ option, which will mention each file, dir, etc. that gets updated in a
+ significant way (a transferred file, a recreated symlink/device, or a
+ touched directory). In addition, if the itemize-changes escape (%i) is
+ included in the string (e.g. if the [`--itemize-changes`](#opt) option was
+ used), the logging of names increases to mention any item that is changed
+ in any way (as long as the receiving side is at least 2.6.4). See the
+ [`--itemize-changes`](#opt) option for a description of the output of "%i".
+
+ Rsync will output the out-format string prior to a file's transfer unless
+ one of the transfer-statistic escapes is requested, in which case the
+ logging is done at the end of the file's transfer. When this late logging
+ is in effect and [`--progress`](#opt) is also specified, rsync will also
+ output the name of the file being transferred prior to its progress
+ information (followed, of course, by the out-format output).
+
+0. `--log-file=FILE`
+
+ This option causes rsync to log what it is doing to a file. This is
+ similar to the logging that a daemon does, but can be requested for the
+ client side and/or the server side of a non-daemon transfer. If specified
+ as a client option, transfer logging will be enabled with a default format
+ of "%i %n%L". See the [`--log-file-format`](#opt) option if you wish to
+ override this.
+
+ Here's an example command that requests the remote side to log what is
+ happening:
+
+ > rsync -av --remote-option=--log-file=/tmp/rlog src/ dest/
+
+ This is very useful if you need to debug why a connection is closing
+ unexpectedly.
+
+ See also [the daemon version of the `--log-file` option](#dopt--log-file).
+
+0. `--log-file-format=FORMAT`
+
+ This allows you to specify exactly what per-update logging is put into the
+ file specified by the [`--log-file`](#opt) option (which must also be
+ specified for this option to have any effect). If you specify an empty
+ string, updated files will not be mentioned in the log file. For a list of
+ the possible escape characters, see the [`log format`](rsyncd.conf.5#log_format)
+ setting in the rsyncd.conf manpage.
+
+ The default FORMAT used if [`--log-file`](#opt) is specified and this
+ option is not is '%i %n%L'.
+
+ See also [the daemon version of the `--log-file-format`
+ option](#dopt--log-file-format).
+
+0. `--stats`
+
+ This tells rsync to print a verbose set of statistics on the file transfer,
+ allowing you to tell how effective rsync's delta-transfer algorithm is for
+ your data. This option is equivalent to [`--info=stats2`](#opt) if
+ combined with 0 or 1 [`-v`](#opt) options, or [`--info=stats3`](#opt) if
+ combined with 2 or more [`-v`](#opt) options.
+
+ The current statistics are as follows:
+
+ - `Number of files` is the count of all "files" (in the generic sense),
+ which includes directories, symlinks, etc. The total count will be
+ followed by a list of counts by filetype (if the total is non-zero). For
+ example: "(reg: 5, dir: 3, link: 2, dev: 1, special: 1)" lists the totals
+ for regular files, directories, symlinks, devices, and special files. If
+ any of value is 0, it is completely omitted from the list.
+ - `Number of created files` is the count of how many "files" (generic
+ sense) were created (as opposed to updated). The total count will be
+ followed by a list of counts by filetype (if the total is non-zero).
+ - `Number of deleted files` is the count of how many "files" (generic
+ sense) were deleted. The total count will be
+ followed by a list of counts by filetype (if the total is non-zero).
+ Note that this line is only output if deletions are in effect, and only
+ if protocol 31 is being used (the default for rsync 3.1.x).
+ - `Number of regular files transferred` is the count of normal files that
+ were updated via rsync's delta-transfer algorithm, which does not include
+ dirs, symlinks, etc. Note that rsync 3.1.0 added the word "regular" into
+ this heading.
+ - `Total file size` is the total sum of all file sizes in the transfer.
+ This does not count any size for directories or special files, but does
+ include the size of symlinks.
+ - `Total transferred file size` is the total sum of all files sizes for
+ just the transferred files.
+ - `Literal data` is how much unmatched file-update data we had to send to
+ the receiver for it to recreate the updated files.
+ - `Matched data` is how much data the receiver got locally when recreating
+ the updated files.
+ - `File list size` is how big the file-list data was when the sender sent
+ it to the receiver. This is smaller than the in-memory size for the file
+ list due to some compressing of duplicated data when rsync sends the
+ list.
+ - `File list generation time` is the number of seconds that the sender
+ spent creating the file list. This requires a modern rsync on the
+ sending side for this to be present.
+ - `File list transfer time` is the number of seconds that the sender spent
+ sending the file list to the receiver.
+ - `Total bytes sent` is the count of all the bytes that rsync sent from the
+ client side to the server side.
+ - `Total bytes received` is the count of all non-message bytes that rsync
+ received by the client side from the server side. "Non-message" bytes
+ means that we don't count the bytes for a verbose message that the server
+ sent to us, which makes the stats more consistent.
+
+0. `--8-bit-output`, `-8`
+
+ This tells rsync to leave all high-bit characters unescaped in the output
+ instead of trying to test them to see if they're valid in the current
+ locale and escaping the invalid ones. All control characters (but never
+ tabs) are always escaped, regardless of this option's setting.
+
+ The escape idiom that started in 2.6.7 is to output a literal backslash
+ (`\`) and a hash (`#`), followed by exactly 3 octal digits. For example, a
+ newline would output as "`\#012`". A literal backslash that is in a
+ filename is not escaped unless it is followed by a hash and 3 digits (0-9).
+
+0. `--human-readable`, `-h`
+
+ Output numbers in a more human-readable format. There are 3 possible levels:
+
+ 1. output numbers with a separator between each set of 3 digits (either a
+ comma or a period, depending on if the decimal point is represented by a
+ period or a comma).
+ 2. output numbers in units of 1000 (with a character suffix for larger
+ units -- see below).
+ 3. output numbers in units of 1024.
+
+ The default is human-readable level 1. Each `-h` option increases the
+ level by one. You can take the level down to 0 (to output numbers as pure
+ digits) by specifying the `--no-human-readable` (`--no-h`) option.
+
+ The unit letters that are appended in levels 2 and 3 are: `K` (kilo), `M`
+ (mega), `G` (giga), `T` (tera), or `P` (peta). For example, a 1234567-byte
+ file would output as 1.23M in level-2 (assuming that a period is your local
+ decimal point).
+
+ Backward compatibility note: versions of rsync prior to 3.1.0 do not
+ support human-readable level 1, and they default to level 0. Thus,
+ specifying one or two `-h` options will behave in a comparable manner in
+ old and new versions as long as you didn't specify a `--no-h` option prior
+ to one or more `-h` options. See the [`--list-only`](#opt) option for one
+ difference.
+
+0. `--partial`
+
+ By default, rsync will delete any partially transferred file if the
+ transfer is interrupted. In some circumstances it is more desirable to
+ keep partially transferred files. Using the `--partial` option tells rsync
+ to keep the partial file which should make a subsequent transfer of the
+ rest of the file much faster.
+
+0. `--partial-dir=DIR`
+
+ This option modifies the behavior of the [`--partial`](#opt) option while
+ also implying that it be enabled. This enhanced partial-file method puts
+ any partially transferred files into the specified _DIR_ instead of writing
+ the partial file out to the destination file. On the next transfer, rsync
+ will use a file found in this dir as data to speed up the resumption of the
+ transfer and then delete it after it has served its purpose.
+
+ Note that if [`--whole-file`](#opt) is specified (or implied), any
+ partial-dir files that are found for a file that is being updated will
+ simply be removed (since rsync is sending files without using rsync's
+ delta-transfer algorithm).
+
+ Rsync will create the _DIR_ if it is missing, but just the last dir -- not
+ the whole path. This makes it easy to use a relative path (such as
+ "`--partial-dir=.rsync-partial`") to have rsync create the
+ partial-directory in the destination file's directory when it is needed,
+ and then remove it again when the partial file is deleted. Note that this
+ directory removal is only done for a relative pathname, as it is expected
+ that an absolute path is to a directory that is reserved for partial-dir
+ work.
+
+ If the partial-dir value is not an absolute path, rsync will add an exclude
+ rule at the end of all your existing excludes. This will prevent the
+ sending of any partial-dir files that may exist on the sending side, and
+ will also prevent the untimely deletion of partial-dir items on the
+ receiving side. An example: the above `--partial-dir` option would add the
+ equivalent of this "perishable" exclude at the end of any other filter
+ rules: `-f '-p .rsync-partial/'`
+
+ If you are supplying your own exclude rules, you may need to add your own
+ exclude/hide/protect rule for the partial-dir because:
+
+ 1. the auto-added rule may be ineffective at the end of your other rules, or
+ 2. you may wish to override rsync's exclude choice.
+
+ For instance, if you want to make rsync clean-up any left-over partial-dirs
+ that may be lying around, you should specify [`--delete-after`](#opt) and
+ add a "risk" filter rule, e.g. `-f 'R .rsync-partial/'`. Avoid using
+ [`--delete-before`](#opt) or [`--delete-during`](#opt) unless you don't
+ need rsync to use any of the left-over partial-dir data during the current
+ run.
+
+ IMPORTANT: the `--partial-dir` should not be writable by other users or it
+ is a security risk! E.g. AVOID "/tmp"!
+
+ You can also set the partial-dir value the [`RSYNC_PARTIAL_DIR`](#)
+ environment variable. Setting this in the environment does not force
+ [`--partial`](#opt) to be enabled, but rather it affects where partial
+ files go when [`--partial`](#opt) is specified. For instance, instead of
+ using `--partial-dir=.rsync-tmp` along with [`--progress`](#opt), you could
+ set [`RSYNC_PARTIAL_DIR=.rsync-tmp`](#) in your environment and then use
+ the [`-P`](#opt) option to turn on the use of the .rsync-tmp dir for
+ partial transfers. The only times that the [`--partial`](#opt) option does
+ not look for this environment value are:
+
+ 1. when [`--inplace`](#opt) was specified (since [`--inplace`](#opt)
+ conflicts with `--partial-dir`), and
+ 2. when [`--delay-updates`](#opt) was specified (see below).
+
+ When a modern rsync resumes the transfer of a file in the partial-dir, that
+ partial file is now updated in-place instead of creating yet another
+ tmp-file copy (so it maxes out at dest + tmp instead of dest + partial +
+ tmp). This requires both ends of the transfer to be at least version
+ 3.2.0.
+
+ For the purposes of the daemon-config's "`refuse options`" setting,
+ `--partial-dir` does _not_ imply [`--partial`](#opt). This is so that a
+ refusal of the [`--partial`](#opt) option can be used to disallow the
+ overwriting of destination files with a partial transfer, while still
+ allowing the safer idiom provided by `--partial-dir`.
+
+0. `--delay-updates`
+
+ This option puts the temporary file from each updated file into a holding
+ directory until the end of the transfer, at which time all the files are
+ renamed into place in rapid succession. This attempts to make the updating
+ of the files a little more atomic. By default the files are placed into a
+ directory named `.~tmp~` in each file's destination directory, but if
+ you've specified the [`--partial-dir`](#opt) option, that directory will be
+ used instead. See the comments in the [`--partial-dir`](#opt) section for
+ a discussion of how this `.~tmp~` dir will be excluded from the transfer,
+ and what you can do if you want rsync to cleanup old `.~tmp~` dirs that
+ might be lying around. Conflicts with [`--inplace`](#opt) and
+ [`--append`](#opt).
+
+ This option implies [`--no-inc-recursive`](#opt) since it needs the full
+ file list in memory in order to be able to iterate over it at the end.
+
+ This option uses more memory on the receiving side (one bit per file
+ transferred) and also requires enough free disk space on the receiving side
+ to hold an additional copy of all the updated files. Note also that you
+ should not use an absolute path to [`--partial-dir`](#opt) unless:
+
+ 1. there is no chance of any of the files in the transfer having the same
+ name (since all the updated files will be put into a single directory if
+ the path is absolute), and
+ 2. there are no mount points in the hierarchy (since the delayed updates
+ will fail if they can't be renamed into place).
+
+ See also the "atomic-rsync" python script in the "support" subdir for an
+ update algorithm that is even more atomic (it uses [`--link-dest`](#opt)
+ and a parallel hierarchy of files).
+
+0. `--prune-empty-dirs`, `-m`
+
+ This option tells the receiving rsync to get rid of empty directories from
+ the file-list, including nested directories that have no non-directory
+ children. This is useful for avoiding the creation of a bunch of useless
+ directories when the sending rsync is recursively scanning a hierarchy of
+ files using include/exclude/filter rules.
+
+ This option can still leave empty directories on the receiving side if you
+ make use of [TRANSFER_RULES](#).
+
+ Because the file-list is actually being pruned, this option also affects
+ what directories get deleted when a delete is active. However, keep in
+ mind that excluded files and directories can prevent existing items from
+ being deleted due to an exclude both hiding source files and protecting
+ destination files. See the perishable filter-rule option for how to avoid
+ this.
+
+ You can prevent the pruning of certain empty directories from the file-list
+ by using a global "protect" filter. For instance, this option would ensure
+ that the directory "emptydir" was kept in the file-list:
+
+ > --filter 'protect emptydir/'
+
+ Here's an example that copies all .pdf files in a hierarchy, only creating
+ the necessary destination directories to hold the .pdf files, and ensures
+ that any superfluous files and directories in the destination are removed
+ (note the hide filter of non-directories being used instead of an exclude):
+
+ > rsync -avm --del --include='*.pdf' -f 'hide,! */' src/ dest
+
+ If you didn't want to remove superfluous destination files, the more
+ time-honored options of `--include='*/' --exclude='*'` would work
+ fine in place of the hide-filter (if that is more natural to you).
+
+0. `--progress`
+
+ This option tells rsync to print information showing the progress of the
+ transfer. This gives a bored user something to watch. With a modern rsync
+ this is the same as specifying [`--info=flist2,name,progress`](#opt), but
+ any user-supplied settings for those info flags takes precedence (e.g.
+ [`--info=flist0 --progress`](#opt)).
+
+ While rsync is transferring a regular file, it updates a progress line that
+ looks like this:
+
+ > 782448 63% 110.64kB/s 0:00:04
+
+ In this example, the receiver has reconstructed 782448 bytes or 63% of the
+ sender's file, which is being reconstructed at a rate of 110.64 kilobytes
+ per second, and the transfer will finish in 4 seconds if the current rate
+ is maintained until the end.
+
+ These statistics can be misleading if rsync's delta-transfer algorithm is
+ in use. For example, if the sender's file consists of the basis file
+ followed by additional data, the reported rate will probably drop
+ dramatically when the receiver gets to the literal data, and the transfer
+ will probably take much longer to finish than the receiver estimated as it
+ was finishing the matched part of the file.
+
+ When the file transfer finishes, rsync replaces the progress line with a
+ summary line that looks like this:
+
+ > 1,238,099 100% 146.38kB/s 0:00:08 (xfr#5, to-chk=169/396)
+
+ In this example, the file was 1,238,099 bytes long in total, the average
+ rate of transfer for the whole file was 146.38 kilobytes per second over
+ the 8 seconds that it took to complete, it was the 5th transfer of a
+ regular file during the current rsync session, and there are 169 more files
+ for the receiver to check (to see if they are up-to-date or not) remaining
+ out of the 396 total files in the file-list.
+
+ In an incremental recursion scan, rsync won't know the total number of
+ files in the file-list until it reaches the ends of the scan, but since it
+ starts to transfer files during the scan, it will display a line with the
+ text "ir-chk" (for incremental recursion check) instead of "to-chk" until
+ the point that it knows the full size of the list, at which point it will
+ switch to using "to-chk". Thus, seeing "ir-chk" lets you know that the
+ total count of files in the file list is still going to increase (and each
+ time it does, the count of files left to check will increase by the number
+ of the files added to the list).
+
+0. `-P`
+
+ The `-P` option is equivalent to "[`--partial`](#opt)
+ [`--progress`](#opt)". Its purpose is to make it much easier to specify
+ these two options for a long transfer that may be interrupted.
+
+ There is also a [`--info=progress2`](#opt) option that outputs statistics
+ based on the whole transfer, rather than individual files. Use this flag
+ without outputting a filename (e.g. avoid `-v` or specify
+ [`--info=name0`](#opt)) if you want to see how the transfer is doing
+ without scrolling the screen with a lot of names. (You don't need to
+ specify the [`--progress`](#opt) option in order to use
+ [`--info=progress2`](#opt).)
+
+ Finally, you can get an instant progress report by sending rsync a signal
+ of either SIGINFO or SIGVTALRM. On BSD systems, a SIGINFO is generated by
+ typing a Ctrl+T (Linux doesn't currently support a SIGINFO signal). When
+ the client-side process receives one of those signals, it sets a flag to
+ output a single progress report which is output when the current file
+ transfer finishes (so it may take a little time if a big file is being
+ handled when the signal arrives). A filename is output (if needed)
+ followed by the [`--info=progress2`](#opt) format of progress info. If you
+ don't know which of the 3 rsync processes is the client process, it's OK to
+ signal all of them (since the non-client processes ignore the signal).
+
+ CAUTION: sending SIGVTALRM to an older rsync (pre-3.2.0) will kill it.
+
+0. `--password-file=FILE`
+
+ This option allows you to provide a password for accessing an rsync daemon
+ via a file or via standard input if **FILE** is `-`. The file should
+ contain just the password on the first line (all other lines are ignored).
+ Rsync will exit with an error if **FILE** is world readable or if a
+ root-run rsync command finds a non-root-owned file.
+
+ This option does not supply a password to a remote shell transport such as
+ ssh; to learn how to do that, consult the remote shell's documentation.
+ When accessing an rsync daemon using a remote shell as the transport, this
+ option only comes into effect after the remote shell finishes its
+ authentication (i.e. if you have also specified a password in the daemon's
+ config file).
+
+0. `--early-input=FILE`
+
+ This option allows rsync to send up to 5K of data to the "early exec"
+ script on its stdin. One possible use of this data is to give the script a
+ secret that can be used to mount an encrypted filesystem (which you should
+ unmount in the the "post-xfer exec" script).
+
+ The daemon must be at least version 3.2.1.
+
+0. `--list-only`
+
+ This option will cause the source files to be listed instead of
+ transferred. This option is inferred if there is a single source arg and
+ no destination specified, so its main uses are:
+
+ 1. to turn a copy command that includes a destination arg into a
+ file-listing command, or
+ 2. to be able to specify more than one source arg. Note: be sure to
+ include the destination.
+
+ CAUTION: keep in mind that a source arg with a wild-card is expanded by the
+ shell into multiple args, so it is never safe to try to specify a single
+ wild-card arg to try to infer this option. A safe example is:
+
+ > rsync -av --list-only foo* dest/
+
+ This option always uses an output format that looks similar to this:
+
+ > drwxrwxr-x 4,096 2022/09/30 12:53:11 support
+ > -rw-rw-r-- 80 2005/01/11 10:37:37 support/Makefile
+
+ The only option that affects this output style is (as of 3.1.0) the
+ [`--human-readable`](#opt) (`-h`) option. The default is to output sizes
+ as byte counts with digit separators (in a 14-character-width column).
+ Specifying at least one `-h` option makes the sizes output with unit
+ suffixes. If you want old-style bytecount sizes without digit separators
+ (and an 11-character-width column) use `--no-h`.
+
+ Compatibility note: when requesting a remote listing of files from an rsync
+ that is version 2.6.3 or older, you may encounter an error if you ask for a
+ non-recursive listing. This is because a file listing implies the
+ [`--dirs`](#opt) option w/o [`--recursive`](#opt), and older rsyncs don't
+ have that option. To avoid this problem, either specify the `--no-dirs`
+ option (if you don't need to expand a directory's content), or turn on
+ recursion and exclude the content of subdirectories: `-r --exclude='/*/*'`.
+
+0. `--bwlimit=RATE`
+
+ This option allows you to specify the maximum transfer rate for the data
+ sent over the socket, specified in units per second. The RATE value can be
+ suffixed with a string to indicate a size multiplier, and may be a
+ fractional value (e.g. `--bwlimit=1.5m`). If no suffix is specified, the
+ value will be assumed to be in units of 1024 bytes (as if "K" or "KiB" had
+ been appended). See the [`--max-size`](#opt) option for a description of
+ all the available suffixes. A value of 0 specifies no limit.
+
+ For backward-compatibility reasons, the rate limit will be rounded to the
+ nearest KiB unit, so no rate smaller than 1024 bytes per second is
+ possible.
+
+ Rsync writes data over the socket in blocks, and this option both limits
+ the size of the blocks that rsync writes, and tries to keep the average
+ transfer rate at the requested limit. Some burstiness may be seen where
+ rsync writes out a block of data and then sleeps to bring the average rate
+ into compliance.
+
+ Due to the internal buffering of data, the [`--progress`](#opt) option may
+ not be an accurate reflection on how fast the data is being sent. This is
+ because some files can show up as being rapidly sent when the data is
+ quickly buffered, while other can show up as very slow when the flushing of
+ the output buffer occurs. This may be fixed in a future version.
+
+ See also [the daemon version of the `--bwlimit` option](#dopt--bwlimit).
+
+0. `--stop-after=MINS`, (`--time-limit=MINS`)
+
+ This option tells rsync to stop copying when the specified number of
+ minutes has elapsed.
+
+ For maximal flexibility, rsync does not communicate this option to the
+ remote rsync since it is usually enough that one side of the connection
+ quits as specified. This allows the option's use even when only one side
+ of the connection supports it. You can tell the remote side about the time
+ limit using [`--remote-option`](#opt) (`-M`), should the need arise.
+
+ The `--time-limit` version of this option is deprecated.
+
+0. `--stop-at=y-m-dTh:m`
+
+ This option tells rsync to stop copying when the specified point in time
+ has been reached. The date & time can be fully specified in a numeric
+ format of year-month-dayThour:minute (e.g. 2000-12-31T23:59) in the local
+ timezone. You may choose to separate the date numbers using slashes
+ instead of dashes.
+
+ The value can also be abbreviated in a variety of ways, such as specifying
+ a 2-digit year and/or leaving off various values. In all cases, the value
+ will be taken to be the next possible point in time where the supplied
+ information matches. If the value specifies the current time or a past
+ time, rsync exits with an error.
+
+ For example, "1-30" specifies the next January 30th (at midnight local
+ time), "14:00" specifies the next 2 P.M., "1" specifies the next 1st of the
+ month at midnight, "31" specifies the next month where we can stop on its
+ 31st day, and ":59" specifies the next 59th minute after the hour.
+
+ For maximal flexibility, rsync does not communicate this option to the
+ remote rsync since it is usually enough that one side of the connection
+ quits as specified. This allows the option's use even when only one side
+ of the connection supports it. You can tell the remote side about the time
+ limit using [`--remote-option`](#opt) (`-M`), should the need arise. Do
+ keep in mind that the remote host may have a different default timezone
+ than your local host.
+
+0. `--fsync`
+
+ Cause the receiving side to fsync each finished file. This may slow down
+ the transfer, but can help to provide peace of mind when updating critical
+ files.
+
+0. `--write-batch=FILE`
+
+ Record a file that can later be applied to another identical destination
+ with [`--read-batch`](#opt). See the "BATCH MODE" section for details, and
+ also the [`--only-write-batch`](#opt) option.
+
+ This option overrides the negotiated checksum & compress lists and always
+ negotiates a choice based on old-school md5/md4/zlib choices. If you want
+ a more modern choice, use the [`--checksum-choice`](#opt) (`--cc`) and/or
+ [`--compress-choice`](#opt) (`--zc`) options.
+
+0. `--only-write-batch=FILE`
+
+ Works like [`--write-batch`](#opt), except that no updates are made on the
+ destination system when creating the batch. This lets you transport the
+ changes to the destination system via some other means and then apply the
+ changes via [`--read-batch`](#opt).
+
+ Note that you can feel free to write the batch directly to some portable
+ media: if this media fills to capacity before the end of the transfer, you
+ can just apply that partial transfer to the destination and repeat the
+ whole process to get the rest of the changes (as long as you don't mind a
+ partially updated destination system while the multi-update cycle is
+ happening).
+
+ Also note that you only save bandwidth when pushing changes to a remote
+ system because this allows the batched data to be diverted from the sender
+ into the batch file without having to flow over the wire to the receiver
+ (when pulling, the sender is remote, and thus can't write the batch).
+
+0. `--read-batch=FILE`
+
+ Apply all of the changes stored in FILE, a file previously generated by
+ [`--write-batch`](#opt). If _FILE_ is `-`, the batch data will be read
+ from standard input. See the "BATCH MODE" section for details.
+
+0. `--protocol=NUM`
+
+ Force an older protocol version to be used. This is useful for creating a
+ batch file that is compatible with an older version of rsync. For
+ instance, if rsync 2.6.4 is being used with the [`--write-batch`](#opt)
+ option, but rsync 2.6.3 is what will be used to run the
+ [`--read-batch`](#opt) option, you should use "--protocol=28" when creating
+ the batch file to force the older protocol version to be used in the batch
+ file (assuming you can't upgrade the rsync on the reading system).
+
+0. `--iconv=CONVERT_SPEC`
+
+ Rsync can convert filenames between character sets using this option.
+ Using a CONVERT_SPEC of "." tells rsync to look up the default
+ character-set via the locale setting. Alternately, you can fully specify
+ what conversion to do by giving a local and a remote charset separated by a
+ comma in the order `--iconv=LOCAL,REMOTE`, e.g. `--iconv=utf8,iso88591`.
+ This order ensures that the option will stay the same whether you're
+ pushing or pulling files. Finally, you can specify either `--no-iconv` or
+ a CONVERT_SPEC of "-" to turn off any conversion. The default setting of
+ this option is site-specific, and can also be affected via the
+ [`RSYNC_ICONV`](#) environment variable.
+
+ For a list of what charset names your local iconv library supports, you can
+ run "`iconv --list`".
+
+ If you specify the [`--secluded-args`](#opt) (`-s`) option, rsync will
+ translate the filenames you specify on the command-line that are being sent
+ to the remote host. See also the [`--files-from`](#opt) option.
+
+ Note that rsync does not do any conversion of names in filter files
+ (including include/exclude files). It is up to you to ensure that you're
+ specifying matching rules that can match on both sides of the transfer.
+ For instance, you can specify extra include/exclude rules if there are
+ filename differences on the two sides that need to be accounted for.
+
+ When you pass an `--iconv` option to an rsync daemon that allows it, the
+ daemon uses the charset specified in its "charset" configuration parameter
+ regardless of the remote charset you actually pass. Thus, you may feel
+ free to specify just the local charset for a daemon transfer (e.g.
+ `--iconv=utf8`).
+
+0. `--ipv4`, `-4` or `--ipv6`, `-6`
+
+ Tells rsync to prefer IPv4/IPv6 when creating sockets or running ssh. This
+ affects sockets that rsync has direct control over, such as the outgoing
+ socket when directly contacting an rsync daemon, as well as the forwarding
+ of the `-4` or `-6` option to ssh when rsync can deduce that ssh is being
+ used as the remote shell. For other remote shells you'll need to specify
+ the "`--rsh SHELL -4`" option directly (or whatever IPv4/IPv6 hint options
+ it uses).
+
+ See also [the daemon version of these options](#dopt--ipv4).
+
+ If rsync was compiled without support for IPv6, the `--ipv6` option will
+ have no effect. The `rsync --version` output will contain "`no IPv6`" if
+ is the case.
+
+0. `--checksum-seed=NUM`
+
+ Set the checksum seed to the integer NUM. This 4 byte checksum seed is
+ included in each block and MD4 file checksum calculation (the more modern
+ MD5 file checksums don't use a seed). 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 checksums, or in the case where the
+ user wants a more random checksum seed. Setting NUM to 0 causes rsync to
+ use the default of **time**() for checksum seed.
+
+## DAEMON OPTIONS
+
+The options allowed when starting an rsync daemon are as follows:
+
+0. `--daemon`
+
+ This tells rsync that it is to run as a daemon. The daemon you start
+ running may be accessed using an rsync client using the `host::module` or
+ `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)](rsyncd.conf.5) manpage for more details.
+
+0. `--address=ADDRESS`
+
+ By default rsync will bind to the wildcard address when run as a daemon
+ with the `--daemon` option. 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](rsyncd.conf.5#address) global option in the
+ rsyncd.conf manpage and the [client version of the `--address`
+ option](#opt--address).
+
+0. `--bwlimit=RATE`
+
+ This option allows you to specify the maximum transfer rate for the data
+ the daemon sends over the socket. The client can still specify a smaller
+ `--bwlimit` value, but no larger value will be allowed.
+
+ See the [client version of the `--bwlimit` option](#opt--bwlimit) for some
+ extra details.
+
+0. `--config=FILE`
+
+ This specifies an alternate config file than the default. This is only
+ relevant when [`--daemon`](#dopt) is specified. The default is
+ /etc/rsyncd.conf unless the daemon is running over a remote shell program
+ and the remote user is not the super-user; in that case the default is
+ rsyncd.conf in the current directory (typically $HOME).
+
+0. `--dparam=OVERRIDE`, `-M`
+
+ This option can be used to set a daemon-config parameter when starting up
+ rsync in daemon mode. It is equivalent to adding the parameter at the end
+ of the global settings prior to the first module's definition. The
+ parameter names can be specified without spaces, if you so desire. For
+ instance:
+
+ > rsync --daemon -M pidfile=/path/rsync.pid
+
+0. `--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 `daemontools` or AIX's `System Resource Controller`.
+ `--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.
+
+0. `--port=PORT`
+
+ This specifies an alternate TCP port number for the daemon to listen on
+ rather than the default of 873.
+
+ See also [the client version of the `--port` option](#opt--port) and the
+ [port](rsyncd.conf.5#port) global setting in the rsyncd.conf manpage.
+
+0. `--log-file=FILE`
+
+ This option tells the rsync daemon to use the given log-file name instead
+ of using the "`log file`" setting in the config file.
+
+ See also [the client version of the `--log-file` option](#opt--log-file).
+
+0. `--log-file-format=FORMAT`
+
+ This option tells the rsync daemon to use the given FORMAT string instead
+ of using the "`log format`" setting in the config file. It also enables
+ "`transfer logging`" unless the string is empty, in which case transfer
+ logging is turned off.
+
+ See also [the client version of the `--log-file-format`
+ option](#opt--log-file-format).
+
+0. `--sockopts`
+
+ This overrides the [`socket options`](rsyncd.conf.5#socket_options)
+ setting in the rsyncd.conf file and has the same syntax.
+
+ See also [the client version of the `--sockopts` option](#opt--sockopts).
+
+0. `--verbose`, `-v`
+
+ This option increases the amount of information the daemon logs during its
+ startup phase. After the client connects, the daemon's verbosity level
+ will be controlled by the options that the client used and the
+ "`max verbosity`" setting in the module's config section.
+
+ See also [the client version of the `--verbose` option](#opt--verbose).
+
+0. `--ipv4`, `-4` or `--ipv6`, `-6`
+
+ 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).
+
+ See also [the client version of these options](#opt--ipv4).
+
+ If rsync was compiled without support for IPv6, the `--ipv6` option will
+ have no effect. The `rsync --version` output will contain "`no IPv6`" if
+ is the case.
+
+0. `--help`, `-h`
+
+ When specified after `--daemon`, print a short help page describing the
+ options available for starting an rsync daemon.
+
+## FILTER RULES
+
+The filter rules allow for custom control of several aspects of how files are
+handled:
+
+- Control which files the sending side puts into the file list that describes
+ the transfer hierarchy
+- Control which files the receiving side protects from deletion when the file
+ is not in the sender's file list
+- Control which extended attribute names are skipped when copying xattrs
+
+The rules are either directly specified via option arguments or they can be
+read in from one or more files. The filter-rule files can even be a part of
+the hierarchy of files being copied, affecting different parts of the tree in
+different ways.
+
+### SIMPLE INCLUDE/EXCLUDE RULES
+
+We will first cover the basics of how include & exclude rules affect what files
+are transferred, ignoring any deletion side-effects. Filter rules mainly
+affect the contents of directories that rsync is "recursing" into, but they can
+also affect a top-level item in the transfer that was specified as a argument.
+
+The default for any unmatched file/dir is for it to be included in the
+transfer, which puts the file/dir into the sender's file list. The use of an
+exclude rule causes one or more matching files/dirs to be left out of the
+sender's file list. An include rule can be used to limit the effect of an
+exclude rule that is matching too many files.
+
+The order of the rules is important because the first rule that matches is the
+one that takes effect. Thus, if an early rule excludes a file, no include rule
+that comes after it can have any effect. This means that you must place any
+include overrides somewhere prior to the exclude that it is intended to limit.
+
+When a directory is excluded, all its contents and sub-contents are also
+excluded. The sender doesn't scan through any of it at all, which can save a
+lot of time when skipping large unneeded sub-trees.
+
+It is also important to understand that the include/exclude rules are applied
+to every file and directory that the sender is recursing into. Thus, if you
+want a particular deep file to be included, you have to make sure that none of
+the directories that must be traversed on the way down to that file are
+excluded or else the file will never be discovered to be included. As an
+example, if the directory "`a/path`" was given as a transfer argument and you
+want to ensure that the file "`a/path/down/deep/wanted.txt`" is a part of the
+transfer, then the sender must not exclude the directories "`a/path`",
+"`a/path/down`", or "`a/path/down/deep`" as it makes it way scanning through
+the file tree.
+
+When you are working on the rules, it can be helpful to ask rsync to tell you
+what is being excluded/included and why. Specifying `--debug=FILTER` or (when
+pulling files) `-M--debug=FILTER` turns on level 1 of the FILTER debug
+information that will output a message any time that a file or directory is
+included or excluded and which rule it matched. Beginning in 3.2.4 it will
+also warn if a filter rule has trailing whitespace, since an exclude of "foo "
+(with a trailing space) will not exclude a file named "foo".
+
+Exclude and include rules can specify wildcard [PATTERN MATCHING RULES](#)
+(similar to shell wildcards) that allow you to match things like a file suffix
+or a portion of a filename.
+
+A rule can be limited to only affecting a directory by putting a trailing slash
+onto the filename.
+
+### SIMPLE INCLUDE/EXCLUDE EXAMPLE
+
+With the following file tree created on the sending side:
+
+> mkdir x/
+> touch x/file.txt
+> mkdir x/y/
+> touch x/y/file.txt
+> touch x/y/zzz.txt
+> mkdir x/z/
+> touch x/z/file.txt
+
+Then the following rsync command will transfer the file "`x/y/file.txt`" and
+the directories needed to hold it, resulting in the path "`/tmp/x/y/file.txt`"
+existing on the remote host:
+
+> rsync -ai -f'+ x/' -f'+ x/y/' -f'+ x/y/file.txt' -f'- *' x host:/tmp/
+
+Aside: this copy could also have been accomplished using the [`-R`](#opt)
+option (though the 2 commands behave differently if deletions are enabled):
+
+> rsync -aiR x/y/file.txt host:/tmp/
+
+The following command does not need an include of the "x" directory because it
+is not a part of the transfer (note the traililng slash). Running this command
+would copy just "`/tmp/x/file.txt`" because the "y" and "z" dirs get excluded:
+
+> rsync -ai -f'+ file.txt' -f'- *' x/ host:/tmp/x/
+
+This command would omit the zzz.txt file while copying "x" and everything else
+it contains:
+
+> rsync -ai -f'- zzz.txt' x host:/tmp/
+
+### FILTER RULES WHEN DELETING
+
+By default the include & exclude filter rules affect both the sender
+(as it creates its file list)
+and the receiver (as it creates its file lists for calculating deletions). If
+no delete option is in effect, the receiver skips creating the delete-related
+file lists. This two-sided default can be manually overridden so that you are
+only specifying sender rules or receiver rules, as described in the [FILTER
+RULES IN DEPTH](#) section.
+
+When deleting, an exclude protects a file from being removed on the receiving
+side while an include overrides that protection (putting the file at risk of
+deletion). The default is for a file to be at risk -- its safety depends on it
+matching a corresponding file from the sender.
+
+An example of the two-sided exclude effect can be illustrated by the copying of
+a C development directory between 2 systems. When doing a touch-up copy, you
+might want to skip copying the built executable and the `.o` files (sender
+hide) so that the receiving side can build their own and not lose any object
+files that are already correct (receiver protect). For instance:
+
+> rsync -ai --del -f'- *.o' -f'- cmd' src host:/dest/
+
+Note that using `-f'-p *.o'` is even better than `-f'- *.o'` if there is a
+chance that the directory structure may have changed. The "p" modifier is
+discussed in [FILTER RULE MODIFIERS](#).
+
+One final note, if your shell doesn't mind unexpanded wildcards, you could
+simplify the typing of the filter options by using an underscore in place of
+the space and leaving off the quotes. For instance, `-f -_*.o -f -_cmd` (and
+similar) could be used instead of the filter options above.
+
+### FILTER RULES IN DEPTH
+
+Rsync supports old-style include/exclude rules and new-style filter rules. The
+older rules are specified using [`--include`](#opt) and [`--exclude`](#opt) as
+well as the [`--include-from`](#opt) and [`--exclude-from`](#opt). These are
+limited in behavior but they don't require a "-" or "+" prefix. An old-style
+exclude rule is turned into a "`- name`" filter rule (with no modifiers) and an
+old-style include rule is turned into a "`+ name`" filter rule (with no
+modifiers).
+
+Rsync builds an ordered list of filter rules as specified on the command-line
+and/or read-in from files. New style filter rules have the following syntax:
+
+> RULE [PATTERN_OR_FILENAME]
+> RULE,MODIFIERS [PATTERN_OR_FILENAME]
+
+You have your choice of using either short or long RULE names, as described
+below. If you use a short-named rule, the ',' separating the RULE from the
+MODIFIERS is optional. The PATTERN or FILENAME that follows (when present)
+must come after either a single space or an underscore (\_). Any additional
+spaces and/or underscores are considered to be a part of the pattern name.
+Here are the available rule prefixes:
+
+0. `exclude, '-'` specifies an exclude pattern that (by default) is both a
+ `hide` and a `protect`.
+0. `include, '+'` specifies an include pattern that (by default) is both a
+ `show` and a `risk`.
+0. `merge, '.'` specifies a merge-file on the client side to read for more
+ rules.
+0. `dir-merge, ':'` specifies a per-directory merge-file. Using this kind of
+ filter rule requires that you trust the sending side's filter checking, so
+ it has the side-effect mentioned under the [`--trust-sender`](#opt) option.
+0. `hide, 'H'` specifies a pattern for hiding files from the transfer.
+ Equivalent to a sender-only exclude, so `-f'H foo'` could also be specified
+ as `-f'-s foo'`.
+0. `show, 'S'` files that match the pattern are not hidden. Equivalent to a
+ sender-only include, so `-f'S foo'` could also be specified as `-f'+s
+ foo'`.
+0. `protect, 'P'` specifies a pattern for protecting files from deletion.
+ Equivalent to a receiver-only exclude, so `-f'P foo'` could also be
+ specified as `-f'-r foo'`.
+0. `risk, 'R'` files that match the pattern are not protected. Equivalent to a
+ receiver-only include, so `-f'R foo'` could also be specified as `-f'+r
+ foo'`.
+0. `clear, '!'` clears the current include/exclude list (takes no arg)
+
+When rules are being read from a file (using merge or dir-merge), empty lines
+are ignored, as are whole-line comments that start with a '`#`' (filename rules
+that contain a hash character are unaffected).
+
+Note also that the [`--filter`](#opt), [`--include`](#opt), and
+[`--exclude`](#opt) 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`](#opt) option, or the [`--include-from`](#opt) /
+[`--exclude-from`](#opt) options.
+
+### PATTERN MATCHING RULES
+
+Most of the rules mentioned above take an argument that specifies what the rule
+should match. If rsync is recursing through a directory hierarchy, keep in
+mind that each pattern is matched against the name of every directory in the
+descent path as rsync finds the filenames to send.
+
+The matching rules for the pattern argument take several forms:
+
+- If a pattern contains a `/` (not counting a trailing slash) or a "`**`"
+ (which can match a slash), then the pattern is matched against the full
+ pathname, including any leading directories within the transfer. If the
+ pattern doesn't contain a (non-trailing) `/` or a "`**`", then it is matched
+ only against the final component of the filename or pathname. For example,
+ `foo` means that the final path component must be "foo" while `foo/bar` would
+ match the last 2 elements of the path (as long as both elements are within
+ the transfer).
+- A pattern that ends with a `/` only matches a directory, not a regular file,
+ symlink, or device.
+- A pattern that starts with a `/` is anchored to the start of the transfer
+ path instead of the end. For example, `/foo/**` or `/foo/bar/**` match only
+ leading elements in the path. If the rule is read from a per-directory
+ filter file, the transfer path being matched will begin at the level of the
+ filter file instead of the top of the transfer. 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.
+
+Rsync chooses between doing a simple string match and wildcard matching by
+checking if the pattern contains one of these three wildcard characters: '`*`',
+'`?`', and '`[`' :
+
+- a '`?`' matches any single character except a slash (`/`).
+- a '`*`' matches zero or more non-slash characters.
+- a '`**`' matches zero or more characters, including slashes.
+- a '`[`' introduces a character class, such as `[a-z]` or `[[:alpha:]]`, that
+ must match one character.
+- a trailing `***` in the pattern is a shorthand that allows you to match a
+ directory and all its contents using a single rule. For example, specifying
+ "`dir_name/***`" will match both the "dir_name" directory (as if "`dir_name/`"
+ had been specified) and everything in the directory (as if "`dir_name/**`"
+ had been specified).
+- a backslash can be used to escape a wildcard character, but it is only
+ interpreted as an escape character if at least one wildcard character is
+ present in the match pattern. For instance, the pattern "`foo\bar`" matches
+ that single backslash literally, while the pattern "`foo\bar*`" would need to
+ be changed to "`foo\\bar*`" to avoid the "`\b`" becoming just "b".
+
+Here are some examples of exclude/include matching:
+
+- Option `-f'- *.o'` would exclude all filenames ending with `.o`
+- Option `-f'- /foo'` would exclude a file (or directory) named foo in the
+ transfer-root directory
+- Option `-f'- foo/'` would exclude any directory named foo
+- Option `-f'- foo/*/bar'` would exclude any file/dir named bar which is at two
+ levels below a directory named foo (if foo is in the transfer)
+- Option `-f'- /foo/**/bar'` would exclude any file/dir named bar that was two
+ or more levels below a top-level directory named foo (note that /foo/bar is
+ **not** excluded by this)
+- Options `-f'+ */' -f'+ *.c' -f'- *'` would include all directories and .c
+ source files but nothing else
+- Options `-f'+ foo/' -f'+ foo/bar.c' -f'- *'` would include only the foo
+ directory and foo/bar.c (the foo directory must be explicitly included or it
+ would be excluded by the "`- *`")
+
+### FILTER RULE MODIFIERS
+
+The following modifiers are accepted after an include (+) or exclude (-) rule:
+
+- A `/` specifies that the include/exclude rule should be matched against the
+ absolute pathname of the current item. For example, `-f'-/ /etc/passwd'`
+ would exclude the passwd file any time the transfer was sending files from
+ the "/etc" directory, and "-/ subdir/foo" would always exclude "foo" when it
+ is in a dir named "subdir", even if "foo" is at the root of the current
+ transfer.
+- A `!` specifies that the include/exclude should take effect if the pattern
+ fails to match. For instance, `-f'-! */'` would exclude all non-directories.
+- A `C` is used to indicate that all the global CVS-exclude rules should be
+ inserted as excludes in place of the "-C". No arg should follow.
+- An `s` is used to indicate that the rule applies to the sending side. When a
+ rule affects the sending side, it affects what files are put into the
+ sender's file list. The default is for a rule to affect both sides unless
+ [`--delete-excluded`](#opt) was specified, in which case default rules become
+ sender-side only. See also the hide (H) and show (S) rules, which are an
+ alternate way to specify sending-side includes/excludes.
+- An `r` is used to indicate that the rule applies to the receiving side. When
+ a rule affects the receiving side, it prevents files from being deleted. See
+ the `s` modifier for more info. See also the protect (P) and risk (R) rules,
+ which are an alternate way to specify receiver-side includes/excludes.
+- A `p` indicates that a rule is perishable, meaning that it is ignored in
+ directories that are being deleted. For instance, the
+ [`--cvs-exclude`](#opt) (`-C`) option's default rules that exclude things
+ like "CVS" and "`*.o`" are marked as perishable, and will not prevent a
+ directory that was removed on the source from being deleted on the
+ destination.
+- An `x` indicates that a rule affects xattr names in xattr copy/delete
+ operations (and is thus ignored when matching file/dir names). If no
+ xattr-matching rules are specified, a default xattr filtering rule is used
+ (see the [`--xattrs`](#opt) option).
+
+### MERGE-FILE FILTER RULES
+
+You can merge whole files into your filter rules by specifying either a merge
+(.) or a dir-merge (:) 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:
+
+> merge /etc/rsync/default.rules
+> . /etc/rsync/default.rules
+> dir-merge .per-dir-filter
+> dir-merge,n- .non-inherited-per-dir-excludes
+> :n- .non-inherited-per-dir-excludes
+
+The following modifiers are accepted after a merge or dir-merge rule:
+
+- A `-` specifies that the file should consist of only exclude patterns, with
+ no other rule-parsing except for in-file comments.
+- A `+` specifies that the file should consist of only include patterns, with
+ no other rule-parsing except for in-file comments.
+- A `C` is a way to specify that the file should be read in a CVS-compatible
+ manner. This turns on 'n', 'w', and '-', but also allows the list-clearing
+ token (!) to be specified. If no filename is provided, ".cvsignore" is
+ assumed.
+- A `e` will exclude the merge-file name from the transfer; e.g. "dir-merge,e
+ .rules" is like "dir-merge .rules" and "- .rules".
+- An `n` specifies that the rules are not inherited by subdirectories.
+- A `w` specifies that the rules are word-split on 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 prefix-parsing wasn't also disabled).
+- You may also specify any of the modifiers for the "+" or "-" rules (above) in
+ order to have the rules that are read in from the file default to having that
+ modifier set (except for the `!` modifier, which would not be useful). For
+ instance, "merge,-/ .excl" would treat the contents of .excl as absolute-path
+ excludes, while "dir-merge,s .filt" and ":sC" would each make all their
+ per-directory rules apply only on the sending side. If the merge rule
+ specifies sides to affect (via the `s` or `r` modifier or both), then the
+ rules in the file must not specify sides (via a modifier or a rule prefix
+ such as `hide`).
+
+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 dir-merge rules are grouped together in the spot where the merge-file
+was specified, so it is possible to override dir-merge 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 rule from a dir-merge file 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 dir-merge filter
+file was found.
+
+Here's an example filter file which you'd specify via `--filter=". file":`
+
+> merge /home/user/.global-filter
+> - *.gz
+> dir-merge .rules
+> + *.[ch]
+> - *.o
+> - foo*
+
+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`](#opt)):
+
+> --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:
+
+> rsync -avF /src/path/ /dest/dir
+> rsync -av --filter=': ../../.rsync-filter' /src/path/ /dest/dir
+> rsync -av --filter=': .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", which creates a dir-merge of the .cvsignore file, but
+parsed in a CVS-compatible manner. You can use this to affect where the
+[`--cvs-exclude`](#opt) (`-C`) option's inclusion of the per-directory
+.cvsignore file gets placed into your rules by putting the ":C" wherever you
+like in your filter rules. Without this, rsync would add the dir-merge rule
+for the .cvsignore file at the end of all your other rules (giving it a lower
+priority than your command-line rules). For example:
+
+> ```
+> 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. To affect the other CVS
+exclude rules (i.e. the default list of exclusions, the contents of
+$HOME/.cvsignore, and the value of $CVSIGNORE) you should omit the `-C`
+command-line option and instead insert a "-C" rule into your filter rules; e.g.
+"`--filter=-C`".
+
+### 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).
+
+### 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`](#opt) 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:
+
+> ```
+> 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`](#opt) and put a / in front of the name (use the
+`--dry-run` option if you're not yet ready to copy any files).
+
+### 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:
+
+> 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`](#opt),
+because this ensures that the receiving side gets all the same exclude rules as
+the sending side before it tries to delete anything:
+
+> 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):
+
+> 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:
+
+> ```
+> rsync -av --filter=':e /.rsync-filter' --delete \
+> host:src/dir /dest
+> rsync -avFF --delete host:src/dir /dest
+> ```
+
+## TRANSFER RULES
+
+In addition to the [FILTER RULES](#) that affect the recursive file scans that
+generate the file list on the sending and (when deleting) receiving sides,
+there are transfer rules. These rules affect which files the generator decides
+need to be transferred without the side effects of an exclude filter rule.
+Transfer rules affect only files and never directories.
+
+Because a transfer rule does not affect what goes into the sender's (and
+receiver's) file list, it cannot have any effect on which files get deleted on
+the receiving side. For example, if the file "foo" is present in the sender's
+list but its size is such that it is omitted due to a transfer rule, the
+receiving side does not request the file. However, its presence in the file
+list means that a delete pass will not remove a matching file named "foo" on
+the receiving side. On the other hand, a server-side exclude (hide) of the
+file "foo" leaves the file out of the server's file list, and absent a
+receiver-side exclude (protect) the receiver will remove a matching file named
+"foo" if deletions are requested.
+
+Given that the files are still in the sender's file list, the
+[`--prune-empty-dirs`](#opt) option will not judge a directory as being empty
+even if it contains only files that the transfer rules omitted.
+
+Similarly, a transfer rule does not have any extra effect on which files are
+deleted on the receiving side, so setting a maximum file size for the transfer
+does not prevent big files from being deleted.
+
+Examples of transfer rules include the default "quick check" algorithm (which
+compares size & modify time), the [`--update`](#opt) option, the
+[`--max-size`](#opt) option, the [`--ignore-non-existing`](#opt) option, and a
+few others.
+
+## BATCH MODE
+
+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.
+
+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.
+
+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 your convenience, a script file is also created when the write-batch option
+is used: it will be named the same as the batch file with ".sh" appended. This
+script file contains a command-line suitable for updating a destination tree
+using the associated batch file. It can be executed using a Bourne (or
+Bourne-like) shell, optionally passing in an alternate destination tree
+pathname which is then used instead of the original destination path. This is
+useful when the destination tree path on the current host differs from the one
+used to create the batch file.
+
+Examples:
+
+> $ rsync --write-batch=foo -a host:/source/dir/ /adest/dir/
+> $ scp foo* remote:
+> $ ssh remote ./foo.sh /bdest/dir/
+
+> $ 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:
+
+- 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.
+- 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.
+- 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`](#opt) 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=-`](#opt) 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 a warning (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`](#opt) 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.
+See also the [`--protocol`](#opt) option for a way to have the creating rsync
+generate a batch file that an older rsync can understand. (Note that batch
+files changed format in version 2.6.3, so mixing versions older than that with
+newer versions will not work.)
+
+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`](#opt) changes to [`--read-batch`](#opt),
+[`--files-from`](#opt) is dropped, and the [`--filter`](#opt) /
+[`--include`](#opt) / [`--exclude`](#opt) options are not needed unless one of
+the [`--delete`](#opt) options is specified.
+
+The code that creates the BATCH.sh file transforms any filter/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`](#opt) 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`](#opt) command for the batched data.
+
+The original batch mode in rsync was based on "rsync+", but the latest
+version uses a new implementation.
+
+## 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 [`--links`](#opt) is specified, then symlinks are added to the transfer
+(instead of being noisily ignored), and the default handling is to recreate
+them with the same target on the destination. Note that [`--archive`](#opt)
+implies [`--links`](#opt).
+
+If [`--copy-links`](#opt) is specified, then symlinks are "collapsed" by
+copying their referent, rather than the symlink.
+
+Rsync can also distinguish "safe" and "unsafe" symbolic links. An example
+where this might be used is a web site mirror that wishes to ensure that the
+rsync module that is copied does not include symbolic links to `/etc/passwd` in
+the public section of the site. Using [`--copy-unsafe-links`](#opt) will cause
+any links to be copied as the file they point to on the destination. Using
+[`--safe-links`](#opt) will cause unsafe links to be omitted by the receiver.
+(Note that you must specify or imply [`--links`](#opt) for
+[`--safe-links`](#opt) to have any effect.)
+
+Symbolic links are considered unsafe if they are absolute symlinks (start with
+`/`), empty, or if they contain enough ".." components to ascend from the top
+of the transfer.
+
+Here's a summary of how the symlink options are interpreted. The list is in
+order of precedence, so if your combination of options isn't mentioned, use the
+first line that is a complete subset of your options:
+
+0. `--copy-links` Turn all symlinks into normal files and directories
+ (leaving no symlinks in the transfer for any other options to affect).
+0. `--copy-dirlinks` Turn just symlinks to directories into real
+ directories, leaving all other symlinks to be handled as described below.
+0. `--links --copy-unsafe-links` Turn all unsafe symlinks
+ into files and create all safe symlinks.
+0. `--copy-unsafe-links` Turn all unsafe symlinks into files, noisily
+ skip all safe symlinks.
+0. `--links --safe-links` The receiver skips creating
+ unsafe symlinks found in the transfer and creates the safe ones.
+0. `--links` Create all symlinks.
+
+For the effect of [`--munge-links`](#opt), see the discussion in that option's
+section.
+
+Note that the [`--keep-dirlinks`](#opt) option does not effect symlinks in the
+transfer but instead affects how rsync treats a symlink to a directory that
+already exists on the receiving side. See that option's section for a warning.
+
+## 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:
+
+> 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.
+
+## EXIT VALUES
+
+- **0** - Success
+- **1** - Syntax or usage error
+- **2** - Protocol incompatibility
+- **3** - Errors selecting input/output files, dirs
+- **4** - Requested action not supported. Either:
+ - an attempt was made to manipulate 64-bit files on a platform that cannot support them
+ - an option was specified that is supported by the client and not by the server
+- **5** - Error starting client-server protocol
+- **6** - Daemon unable to append to log-file
+- **10** - Error in socket I/O
+- **11** - Error in file I/O
+- **12** - Error in rsync protocol data stream
+- **13** - Errors with program diagnostics
+- **14** - Error in IPC code
+- **20** - Received SIGUSR1 or SIGINT
+- **21** - Some error returned by **waitpid()**
+- **22** - Error allocating core memory buffers
+- **23** - Partial transfer due to error
+- **24** - Partial transfer due to vanished source files
+- **25** - The --max-delete limit stopped deletions
+- **30** - Timeout in data send/receive
+- **35** - Timeout waiting for daemon connection
+
+## ENVIRONMENT VARIABLES
+
+0. `CVSIGNORE`
+
+ The CVSIGNORE environment variable supplements any ignore patterns in
+ .cvsignore files. See the [`--cvs-exclude`](#opt) option for more details.
+
+0. `RSYNC_ICONV`
+
+ Specify a default [`--iconv`](#opt) setting using this environment
+ variable. First supported in 3.0.0.
+
+0. `RSYNC_OLD_ARGS`
+
+ Specify a "1" if you want the [`--old-args`](#opt) option to be enabled by
+ default, a "2" (or more) if you want it to be enabled in the
+ repeated-option state, or a "0" to make sure that it is disabled by
+ default. When this environment variable is set to a non-zero value, it
+ supersedes the [`RSYNC_PROTECT_ARGS`](#) variable.
+
+ This variable is ignored if [`--old-args`](#opt), `--no-old-args`, or
+ [`--secluded-args`](#opt) is specified on the command line.
+
+ First supported in 3.2.4.
+
+0. `RSYNC_PROTECT_ARGS`
+
+ Specify a non-zero numeric value if you want the [`--secluded-args`](#opt)
+ option to be enabled by default, or a zero value to make sure that it is
+ disabled by default.
+
+ This variable is ignored if [`--secluded-args`](#opt), `--no-secluded-args`,
+ or [`--old-args`](#opt) is specified on the command line.
+
+ First supported in 3.1.0. Starting in 3.2.4, this variable is ignored if
+ [`RSYNC_OLD_ARGS`](#) is set to a non-zero value.
+
+0. `RSYNC_RSH`
+
+ This 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 [`--rsh`](#opt) (`-e`) option.
+
+0. `RSYNC_PROXY`
+
+ This environment variable allows you to redirect your rsync
+ client to use a web proxy when connecting to an rsync daemon. You should
+ set `RSYNC_PROXY` to a hostname:port pair.
+
+0. `RSYNC_PASSWORD`
+
+ This environment variable allows you to set the password for an rsync
+ **daemon** connection, which avoids the password prompt. Note that this
+ does **not** supply a password to a remote shell transport such as ssh
+ (consult its documentation for how to do that).
+
+0. `USER` or `LOGNAME`
+
+ The USER or LOGNAME environment variables are used to determine the default
+ username sent to an rsync daemon. If neither is set, the username defaults
+ to "nobody". If both are set, `USER` takes precedence.
+
+0. `RSYNC_PARTIAL_DIR`
+
+ This environment variable specifies the directory to use for a
+ [`--partial`](#opt) transfer without implying that partial transfers be
+ enabled. See the [`--partial-dir`](#opt) option for full details.
+
+0. `RSYNC_COMPRESS_LIST`
+
+ This environment variable allows you to customize the negotiation of the
+ compression algorithm by specifying an alternate order or a reduced list of
+ names. Use the command `rsync --version` to see the available compression
+ names. See the [`--compress`](#opt) option for full details.
+
+0. `RSYNC_CHECKSUM_LIST`
+
+ This environment variable allows you to customize the negotiation of the
+ checksum algorithm by specifying an alternate order or a reduced list of
+ names. Use the command `rsync --version` to see the available checksum
+ names. See the [`--checksum-choice`](#opt) option for full details.
+
+0. `RSYNC_MAX_ALLOC`
+
+ This environment variable sets an allocation maximum as if you had used the
+ [`--max-alloc`](#opt) option.
+
+0. `RSYNC_PORT`
+
+ This environment variable is not read by rsync, but is instead set in
+ its sub-environment when rsync is running the remote shell in combination
+ with a daemon connection. This allows a script such as
+ [`rsync-ssl`](rsync-ssl.1) to be able to know the port number that the user
+ specified on the command line.
+
+0. `HOME`
+
+ This environment variable is used to find the user's default .cvsignore
+ file.
+
+0. `RSYNC_CONNECT_PROG`
+
+ This environment variable is mainly used in debug setups to set the program
+ to use when making a daemon connection. See [CONNECTING TO AN RSYNC
+ DAEMON](#) for full details.
+
+0. `RSYNC_SHELL`
+
+ This environment variable is mainly used in debug setups to set the program
+ to use to run the program specified by [`RSYNC_CONNECT_PROG`](#). See
+ [CONNECTING TO AN RSYNC DAEMON](#) for full details.
+
+## FILES
+
+/etc/rsyncd.conf or rsyncd.conf
+
+## SEE ALSO
+
+[**rsync-ssl**(1)](rsync-ssl.1), [**rsyncd.conf**(5)](rsyncd.conf.5), [**rrsync**(1)](rrsync.1)
+
+## BUGS
+
+- Times are transferred as \*nix time_t values.
+- When transferring to FAT filesystems rsync may re-sync unmodified files. See
+ the comments on the [`--modify-window`](#opt) option.
+- File permissions, devices, etc. are transferred as native numerical values.
+- See also the comments on the [`--delete`](#opt) option.
+
+Please report bugs! See the web site at <https://rsync.samba.org/>.
+
+## VERSION
+
+This manpage is current for version @VERSION@ of rsync.
+
+## INTERNAL OPTIONS
+
+The options `--server` and `--sender` are used internally by rsync, and should
+never be typed by a user under normal circumstances. Some awareness of these
+options may be needed in certain scenarios, such as when setting up a login
+that can only run an rsync command. For instance, the support directory of the
+rsync distribution has an example script named rrsync (for restricted rsync)
+that can be used with a restricted ssh login.
+
+## CREDITS
+
+Rsync is distributed under the GNU General Public License. See the file
+[COPYING](COPYING) for details.
+
+An rsync web site is available at <https://rsync.samba.org/>. The site
+includes an FAQ-O-Matic which may cover questions unanswered by this manual
+page.
+
+The rsync github project is <https://github.com/WayneD/rsync>.
+
+We would be delighted to hear from you if you like this program. Please
+contact the mailing-list at <rsync@lists.samba.org>.
+
+This program uses the excellent zlib compression library written by Jean-loup
+Gailly and Mark Adler.
+
+## THANKS
+
+Special thanks go out to: John Van Essen, Matt McCutchen, Wesley W. Terpstra,
+David Dykstra, Jos Backus, Sebastian Krahmer, Martin Pool, and our
+gone-but-not-forgotten compadre, J.W. Schultz.
+
+Thanks also to Richard Brent, Brendan Mackay, Bill Waite, Stephen Rothwell and
+David Bell. I've probably missed some people, my apologies if I have.
+
+## AUTHOR
+
+Rsync was originally written by Andrew Tridgell and Paul Mackerras. Many
+people have later contributed to it. It is currently maintained by Wayne
+Davison.
+
+Mailing lists for support and development are available at
+<https://lists.samba.org/>.