On Tue, May 24, 2005 at 05:45:59PM +0200, Frank Post
wrote:> Why does rsync delete this files despite that the files are there and
> gets sync'ed ?
The problem is that the call to flist_find() is not finding the file by
name in the file-list, so it deletes it. This is apparently due to the
presence of a dot dir down in the file list (which happens when relative
is enabled and a dir has a trailing slash) combined with a subtle bug in
f_name_cmp() during the --delete phase.
> /etc/mail/spamfilter/mx1/ is part of files-to-sync
A work-around for rsync 2.6.4 and 2.6.5pre[12] is to not put a trailing
slash on a source directory name when combining --relative/-R (which is
implied by --files-from) with --recursive/-r and --delete.
A patch that fixes f_name_cmp() is attached. I'm also considering a more
extensive change that would simplify the logic in f_name_cmp(), but that
will have to wait until after 2.6.5 gets released.
Thanks for the report!
..wayne..
-------------- next part --------------
--- flist.c 14 May 2005 18:44:57 -0000 1.294
+++ flist.c 25 May 2005 00:55:25 -0000
@@ -1680,8 +1680,13 @@ int f_name_cmp(struct file_struct *f1, s
break;
case s_SLASH:
type1 = S_ISDIR(f1->mode) ? t_path : t_ITEM;
- state1 = s_BASE;
c1 = (uchar*)f1->basename;
+ if (type1 == t_PATH && *c1 == '.' && !c1[1]) {
+ type1 = t_ITEM;
+ state1 = s_TRAILING;
+ c1 = (uchar*)"";
+ } else
+ state1 = s_BASE;
break;
case s_BASE:
state1 = s_TRAILING;
@@ -1705,8 +1710,13 @@ int f_name_cmp(struct file_struct *f1, s
break;
case s_SLASH:
type2 = S_ISDIR(f2->mode) ? t_path : t_ITEM;
- state2 = s_BASE;
c2 = (uchar*)f2->basename;
+ if (type2 == t_PATH && *c2 == '.' && !c2[1]) {
+ type2 = t_ITEM;
+ state2 = s_TRAILING;
+ c2 = (uchar*)"";
+ } else
+ state2 = s_BASE;
break;
case s_BASE:
state2 = s_TRAILING;