Point out that the file_struct in log_delete is zero-initialized because

[rsync/rsync.git] / rsyncd.conf.yo

diff --git a/rsyncd.conf.yo b/rsyncd.conf.yo
index f7f483b..240c63a 100644 (file)
--- a/rsyncd.conf.yo
+++ b/rsyncd.conf.yo
@@ -156,6 +156,12 @@ For example, this would use the authorizing user's name in the path:
 
 verb(    path = /home/%RSYNC_USER_NAME% )
 
+It is fine if the path includes internal spaces -- they will be retained
+verbatim (which means that you shouldn't try to escape them).  If your final
+directory has a trailing space (and this is somehow not something you wish to
+fix), append a trailing slash to the path to avoid losing the trailing
+whitespace.
+
 dit(bf(use chroot)) If "use chroot" is true, the rsync daemon will chroot
 to the "path" before starting the file transfer with the client.  This has
 the advantage of extra protection against possible implementation security
@@ -706,7 +712,12 @@ the sender.
 
 dit(bf(pre-xfer exec), bf(post-xfer exec)) You may specify a command to be run
 before and/or after the transfer.  If the bf(pre-xfer exec) command fails, the
-transfer is aborted before it begins.
+transfer is aborted before it begins.  Any output from the script on stdout (up
+to several KB) will be displayed to the user when aborting, but is NOT
+displayed if the script returns success.  Any output from the script on stderr
+goes to the daemon's stderr, which is typically discarded (though see
+--no-detatch option for a way to see the stderr output, which can assist with
+debugging).
 
 The following environment variables will be set, though some are
 specific to the pre-xfer or the post-xfer environment:
@@ -756,7 +767,8 @@ parameters in a module started in another file, can affect the defaults for
 other files, etc.
 
 When an bf(&include) or bf(&merge) directive refers to a directory, it will read
-in all the bf(*.conf) files contained inside that directory (without any
+in all the bf(*.conf) or bf(*.inc) files (respectively) that are contained inside
+that directory (without any
 recursive scanning), with the files sorted into alpha order.  So, if you have a
 directory named "rsyncd.d" with the files "foo.conf", "bar.conf", and
 "baz.conf" inside it, this directive:
@@ -773,17 +785,25 @@ except that it adjusts as files are added and removed from the directory.
 
 The advantage of the bf(&include) directive is that you can define one or more
 modules in a separate file without worrying about unintended side-effects
-between the self-contained module files.  For instance, this is a useful
-/etc/rsyncd.conf file:
+between the self-contained module files.
+
+The advantage of the bf(&merge) directive is that you can load config snippets
+that can be included into multiple module definitions, and you can also set
+global values that will affect connections (such as bf(motd file)), or globals
+that will affect other include files.
+
+For example, this is a useful /etc/rsyncd.conf file:
 
 verb(    port = 873
     log file = /var/log/rsync.log
     pid file = /var/lock/rsync.lock
 
+    &merge /etc/rsyncd.d
     &include /etc/rsyncd.d )
 
-The advantage of the bf(&merge) directive is that you can load config snippets
-that can be included into multiple module definitions.
+This would merge any /etc/rsyncd.d/*.inc files (for global values that should
+stay in effect), and then include any /etc/rsyncd.d/*.conf files (defining
+modules without any global-value cross-talk).
 
 manpagesection(AUTHENTICATION STRENGTH)