+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.
+
+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 in 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 bf(--delay-updates) 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 bf(--partial-dir) 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 bf(--partial-dir) with
+an absolute path does not have this side-effect.)
+
+dit(bf(-y, --fuzzy)) 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.
+
+Note that the use of the bf(--delete) option might get rid of any potential
+fuzzy-match files, so either use bf(--delete-after) or specify some
+filename exclusions if you need to prevent this.
+
+dit(bf(--compare-dest=DIR)) This option instructs rsync to use em(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 em(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.
+
+Beginning in version 2.6.4, multiple bf(--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 em(DIR)s will be
+selected to try to speed up the transfer.
+
+If em(DIR) is a relative path, it is relative to the destination directory.
+See also bf(--copy-dest) and bf(--link-dest).
+
+dit(bf(--copy-dest=DIR)) This option behaves like bf(--compare-dest), but
+rsync will also copy unchanged files found in em(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 bf(--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 em(DIR)s will be
+selected to try to speed up the transfer.
+
+If em(DIR) is a relative path, it is relative to the destination directory.
+See also bf(--compare-dest) and bf(--link-dest).
+
+dit(bf(--link-dest=DIR)) This option behaves like bf(--copy-dest), but
+unchanged files are hard linked from em(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:
+
+quote(tt( rsync -av --link-dest=$PWD/prior_dir host:src_dir/ new_dir/))
+
+Beginning in version 2.6.4, multiple bf(--link-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 em(DIR)s will be
+selected to try to speed up the transfer.
+
+This option works best when copying into an empty destination hierarchy, as
+rsync treats existing files as definitive (so it never looks in the link-dest
+dirs when a destination file already exists), and as malleable (so it might
+change the attributes of a destination file, which affects all the hard-linked
+versions).
+
+Note that if you combine this option with bf(--ignore-times), 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 em(DIR) is a relative path, it is relative to the destination directory.
+See also bf(--compare-dest) and bf(--copy-dest).
+
+Note that rsync versions prior to 2.6.1 had a bug that could prevent
+bf(--link-dest) from working properly for a non-super-user when bf(-o) was
+specified (or implied by bf(-a)). You can work-around this bug by avoiding
+the bf(-o) option when sending to an old rsync.
+
+dit(bf(-z, --compress)) 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.
+
+Note that this option typically achieves better compression ratios than can
+be achieved by using a compressing remote shell or a compressing transport
+because it takes advantage of the implicit information in the matching data
+blocks that are not explicitly sent over the connection.
+
+See the bf(--skip-compress) option for the default list of file suffixes
+that will not be compressed.
+
+dit(bf(--compress-level=NUM)) Explicitly set the compression level to use
+(see bf(--compress)) instead of letting it default. If NUM is non-zero,
+the bf(--compress) option is implied.
+
+dit(bf(--skip-compress=LIST)) Override the list of file suffixes that will
+not be compressed. The bf(LIST) should be one or more file suffixes
+(without the dot) separated by slashes (/).
+
+You may specify an empty string to indicate that no file 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).
+
+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):
+
+verb( --skip-compress=gz/jpg/mp[34]/7z/bz2)
+
+The default list of suffixes that will not be compressed is this (several
+of these are newly added for 3.0.0):
+
+verb( gz/zip/z/rpm/deb/iso/bz2/t[gb]z/7z/mp[34]/mov/avi/ogg/jpg/jpeg)
+
+This list will be replaced by your bf(--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).