+dit(bf(--munge-links)) This option tells rsync to (1) modify all symlinks on
+the receiving side in a way that makes them unusable but recoverable (see
+below), or (2) to unmunge symlinks on the sending side that had been stored in
+a munged state. This is useful if you don't quite trust the source of the data
+to not try to slip in a symlink to a unexpected place.
+
+The way rsync disables the use of symlinks is to prefix each one with the
+string "/rsyncd-munged/". This prevents the links from being used as long as
+that 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.
+
+The option only affects the client side of the transfer, so if you need it to
+affect the server, specify it via bf(--remote-option). (Note that in a local
+transfer, the client side is the sender.)
+
+This option has no affect on a daemon, since the daemon configures whether it
+wants munged symlinks via its "munge symlinks" parameter. See also the
+"munge-symlinks" perl script in the support directory of the source code.
+
+dit(bf(-k, --copy-dirlinks)) 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 bf(--copy-links).
+
+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
+bf(--force) or bf(--delete) is in effect).
+
+See also bf(--keep-dirlinks) for an analogous option for the receiving
+side.
+
+dit(bf(-K, --keep-dirlinks)) 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
+bf(--keep-dirlinks), the receiver deletes symlink "foo", recreates it as a
+directory, and receives the file into the new directory. With
+bf(--keep-dirlinks), the receiver keeps the symlink and "file" ends up in
+"bar".
+
+One note of caution: if you use bf(--keep-dirlinks), you must trust all
+the symlinks in the copy! If it is possible for an untrusted user to
+create their own symlink to any 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 bf(--copy-dirlinks) for an analogous option for the sending side.
+
+dit(bf(-H, --hard-links)) This tells rsync to look for hard-linked files in
+the transfer and link together the corresponding files on the receiving
+side. Without this option, hard-linked files in the transfer are treated
+as though they were separate files.
+
+When you are updating a non-empty destination, this option only ensures
+that files that are hard-linked together on the source are hard-linked
+together on the destination. It does NOT currently endeavor to break
+already existing hard links on the destination that do not exist between
+the source files. Note, however, that if one or more extra-linked files
+have content changes, they will become unlinked when updated (assuming you
+are not using the bf(--inplace) option).
+
+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 bf(--inplace) 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 bf(--inplace) option for more caveats).
+
+If incremental recursion is active (see bf(--recursive)), 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, just its efficiency. One way to avoid this is to disable
+incremental recursion using the bf(--no-inc-recursive) option.
+
+dit(bf(-p, --perms)) This option causes the receiving rsync to set the
+destination permissions to be the same as the source permissions. (See
+also the bf(--chmod) option for a way to modify what rsync considers to
+be the source permissions.)
+
+When this option is em(off), permissions are set as follows:
+
+quote(itemization(
+ it() Existing files (including updated files) retain their existing
+ permissions, though the bf(--executability) option might change just
+ the execute permission for the file.
+ it() 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 bf(--perms) and bf(--executability) are both disabled,
+rsync's behavior is the same as that of other file-copy utilities,
+such as bf(cp)(1) and bf(tar)(1).
+
+In summary: to give destination files (both old and new) the source
+permissions, use bf(--perms). To give new files the destination-default
+permissions (while leaving existing files unchanged), make sure that the
+bf(--perms) option is off and use bf(--chmod=ugo=rwX) (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 bf(-Z) option,
+and includes --no-g to use the default group of the destination dir):
+
+quote(tt( rsync alias -Z --no-p --no-g --chmod=ugo=rwX))
+
+You could then use this new option in a command such as this one:
+
+quote(tt( rsync -avZ src/ dest/))
+
+(Caveat: make sure that bf(-a) does not follow bf(-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 bf(--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 bf(--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.)
+
+dit(bf(-E, --executability)) This option causes rsync to preserve the
+executability (or non-executability) of regular files when bf(--perms) 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:
+
+quote(itemization(
+ it() To make a file non-executable, rsync turns off all its 'x'
+ permissions.
+ it() To make a file executable, rsync turns on each 'x' permission that
+ has a corresponding 'r' permission enabled.
+))