From 242f6052c2423e21406289e4d091318a657a5222 Mon Sep 17 00:00:00 2001 From: Wayne Davison Date: Sun, 8 Oct 2006 22:17:39 +0000 Subject: [PATCH] Mention the latest bug fix. --- NEWS | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index bfc2d836..32c03886 100644 --- a/NEWS +++ b/NEWS @@ -21,7 +21,7 @@ Changes since 2.6.8: - Fixed an overzealous sanitizing bug in the handling of the --link-dest, --copy-dest, and --compare-dest options to a daemon without chroot: if the copy's destination dir is deeper than the top of the module's path, - these options now accept a safe number of ../ (parent-dir) references + these options now accept a safe number of parent-dir (../) references (since these options are relative to the destination dir). The old code incorrectly chopped off all "../" prefixes for these options, no matter how deep the destination directory was in the module's hierarchy. @@ -34,6 +34,10 @@ Changes since 2.6.8: process. (These problems could only affect an rsync daemon that was receiving files.) + - Fixed a bug where using --dry-run with a --*-dest option with a path + relative to a directory that does not yet exist: the affected option + gets its proper path value so that the output of the dry-run is right. + - Fixed a bug in the %f logfile escape when receiving files: the destination path is now included in the output (e.g. you can now tell when a user specifies a subdir inside a module). @@ -73,7 +77,7 @@ Changes since 2.6.8: - If either --remove-source-files or --remove-sent-files is enabled and we are unable to remove the source file, rsync now outputs an error. - - Fixed a bug in the daemon's "incoming chmod" rule: newly-created + - Fixed a bug in the daemon's "incoming chmod" rule: newly-created directories no longer get the 'F' (file) rules applied to them. ENHANCEMENTS: -- 2.34.1