+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.
+
+bf(--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 bf(--relative)
+to make the paths match up right. For example:
+
+quote(tt(rsync -r --relative src/./ src/./follow-me/ dest/))
+
+This works because rsync calls bf(lstat)(2) on the source arg as given, and the
+trailing slash makes bf(lstat)(2) follow the symlink, giving rise to a directory
+in the file-list which overrides the symlink found during the scan of "src/./".
+
+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 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:
+
+quote(itemization(
+ it() If the destination contains extraneous hard-linked files, rsync 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 bf(--inplace) option).
+ it() If you specify a bf(--link-dest) directory that contains hard links,
+ the linking of the destination files against the bf(--link-dest) files can
+ cause some paths in the destination to become linked together due to the
+ bf(--link-dest) 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 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 (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 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.
+))