Improved the usage comments.
[rsync/rsync.git] / rsync.yo
index 60149d6..9298292 100644 (file)
--- a/rsync.yo
+++ b/rsync.yo
@@ -3,20 +3,20 @@ manpage(rsync)(1)(28 Jul 2005)()()
 manpagename(rsync)(faster, flexible replacement for rcp)
 manpagesynopsis()
 
+rsync [OPTION]... SRC [SRC]... DEST
+
 rsync [OPTION]... SRC [SRC]... [USER@]HOST:DEST
 
-rsync [OPTION]... [USER@]HOST:SRC [DEST]
+rsync [OPTION]... SRC [SRC]... [USER@]HOST::DEST
 
-rsync [OPTION]... SRC [SRC]... DEST
+rsync [OPTION]... SRC [SRC]... rsync://[USER@]HOST[:PORT]/DEST
 
-rsync [OPTION]... [USER@]HOST::SRC [DEST]
+rsync [OPTION]... [USER@]HOST:SRC [DEST]
 
-rsync [OPTION]... SRC [SRC]... [USER@]HOST::DEST
+rsync [OPTION]... [USER@]HOST::SRC [DEST]
 
 rsync [OPTION]... rsync://[USER@]HOST[:PORT]/SRC [DEST]
 
-rsync [OPTION]... SRC [SRC]... rsync://[USER@]HOST[:PORT]/DEST
-
 manpagedescription()
 
 rsync is a program that behaves in much the same way that rcp does,
@@ -733,7 +733,9 @@ also excluded from being deleted unless you use the bf(--delete-excluded)
 option or mark the rules as only matching on the sending side (see the
 include/exclude modifiers in the FILTER RULES section).
 
-This option has no effect unless directory recursion is enabled.
+Prior to rsync 2.6.7, this option would have no effect unless bf(--recursive)
+was in effect.  Beginning with 2.6.7, deletions will also occur when bf(--dirs)
+is specified, but only for directories whose contents are being copied.
 
 This option can be dangerous if used incorrectly!  It is a very good idea
 to run first using the bf(--dry-run) option (bf(-n)) to see what files would be
@@ -1260,10 +1262,13 @@ Conflicts with bf(--inplace).
 This option uses more memory on the receiving side (one bit per file
 transferred) and also requires enough free disk space on the receiving
 side to hold an additional copy of all the updated files.  Note also that
-you should not use an absolute path to bf(--partial-dir) unless there is no
+you should not use an absolute path to bf(--partial-dir) unless (1)
+there is no
 chance of any of the files in the transfer having the same name (since all
 the updated files will be put into a single directory if the path is
-absolute).
+absolute)
+and (2) there are no mount points in the hierarchy (since the
+delayed updates will fail if they can't be renamed into place).
 
 See also the "atomic-rsync" perl script in the "support" subdir for an
 update algorithm that is even more atomic (it uses bf(--link-dest) and a