-dit(bf(-H, --hard-links)) This tells rsync to recreate hard links on
-the remote system to be the same as the local system. Without this
-option hard links are treated like regular files.
-
-Note that rsync can only detect hard links if both parts of the link
-are in the list of files being sent.
-
-This option can be quite slow, so only use it if you need it.
-
-dit(bf(-K, --keep-dirlinks)) On the receiving side, if a symlink is
-pointing to a directory, it will be treated as matching a directory
-from the sender.
-
-dit(bf(-W, --whole-file)) With this option the incremental rsync algorithm
-is not used and the whole file is sent as-is instead. 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.
+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.