--delete-delay find deletions during, delete after
--delete-after receiver deletes after transfer, not before
--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
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 MD4 checksum for each file that has a
+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 (and
this is prior to any reading that will be done to transfer changed files),
automatic after-the-transfer verification has nothing to do with this
option's before-the-transfer "Does this file need to be updated?" check.
+For protocol 30 and beyond (first supported in 3.0.0), the checksum used is
+MD5. For older protocols, the checksum used is MD4.
+
dit(bf(-a, --archive)) This is equivalent to bf(-rlptgoD). It is a quick
way of saying you want recursion and want to preserve almost
everything (with -H being a notable omission).
bf(--delete-excluded).
See bf(--delete) (which is implied) for more details on file-deletion.
+dit(bf(--ignore-missing-args)) When rsync is first processing the explicitly
+requested source files (e.g. command-line arguments or bf(--files-from)
+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.
+
+dit(bf(--delete-missing-args)) This option takes the behavior of (the implied)
+bf(--ignore-missing-args) 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 or --delete 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 bf(--list-only) output.
+
dit(bf(--ignore-errors)) Tells bf(--delete) to go ahead and delete files
even when there are I/O errors.
For a list of the possible escape characters, see the "log format" setting
in the rsyncd.conf manpage.
+The default FORMAT used if bf(--log-file) is specified and this option is not
+is '%i %n%L'.
+
dit(bf(--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 bf(--info=stats2)
When the file transfer finishes, rsync replaces the progress line with a
summary line that looks like this:
-verb( 1238099 100% 146.38kB/s 0:00:08 (xfer#5, to-check=169/396))
+verb( 1,238,099 100% 146.38kB/s 0:00:08 (xfr#5, to-chk=169/396))
-In this example, the file was 1238099 bytes long in total, the average rate
+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).
+
dit(bf(-P)) The bf(-P) option is equivalent to bf(--partial) bf(--progress). Its
purpose is to make it much easier to specify these two options for a long
transfer that may be interrupted.
will have no effect. The bf(--version) output will tell you if this
is the case.
-dit(bf(--checksum-seed=NUM)) Set the MD4 checksum seed to the integer
+dit(bf(--checksum-seed=NUM)) Set the checksum seed to the integer
NUM. This 4 byte checksum seed is included in each block and file
-MD4 checksum calculation. By default the checksum seed is generated
+checksum calculation. By default the checksum seed is generated
by the server and defaults to the current code(time()). This option
is used to set a specific checksum seed, which is useful for
applications that want repeatable block and file checksums, or
client to store in a "batch file" all the information needed to repeat
this operation against other, identical destination trees.
-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 convenience, one additional file is creating when the write-batch
-option is used. This file's name is created by appending
-".sh" to the batch filename. The .sh file contains
-a command-line suitable for updating a destination tree using that
-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 path. This is useful when the destination tree
-path differs from the original destination tree path.
-
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:
quote(
Matt McCutchen's Web Site / rsync / rsync.git / blobdiff