rsync - May 2005 - Possible bug - delete complains about parent directory in new version

I have what I believe to be a bug in the behavior of the current (2.6.4) 
version of rsync.  While trying to upgrade from version 2.5.2 to the 
current version (for security concerns), I noticed the following 
difference in behavior between the two versions which is preventing the 
upgrade:

If you have a directory tree on the target such as the following:

  dir/pdf/file1.pdf
  dir/pdf/file2.pdf
  ...
  dir/pdf/fileN.pdf

If the "dir/pdf" directory does not exist on the source, and you have
an
exclude list which excludes "*.pdf", rsync 2.6.4 fails to synchronize 
the two directories - it fails with:

    rsync: delete_file: rmdir "dir/pdf" failed: File exists (17)
    ...
    rsync error: some files could not be transferred (code 23) at
    main.c(789)

However version 2.5.2 quietly synchronizes the two directory trees 
without error.

The error (17) above is due to the fact that "dir/pdf" still contains 
file*.pdf.  However, since "dir/pdf" does not exist on the source, it 
tries to remove the directory, even though the directory is not empty.  
Version 2.5.2 seems "smart" enought to realize that it should not 
attempt to delete a directory containing an excluded file, but 2.6.4 
blindly tries to delete the directory which is why I call this a 
"possible bug".

One might be tempted to simply tell me "Why not exclude
'pdf/'?" or
similar.  However, in this case you run into exactly the same problem if 
the parent of "pdf" does not exist.  The problem is not fixed it's
moved...

The directory trees hinted at above are actually used for independent 
web developer synchronization to a single target web-site tree.  
Different folk do the web development, image development, and pdf 
creation.  Each group has their own rsync scripts which 'layer in' the 
content from their respective trees, which explains why the "pdf" 
directories do not (always) exist on the source (and are excluded).  
Also, the "pdf" (and other similar directories) are not at consistent,
predictable locations in the directory tree, which make detailed exclude 
lists unworkable.  Again, all works fine with version 2.5.2, but fails 
with 2.6.4.

The rsync command used is as follows:

/usr/local/bin/rsync -rl -v -v --delete --exclude-from=exclude-list
--rsh="ssh -i $HOME/.ssh/rsync_key" --rsync-path=/usr/local/bin/rsync
/source_dir host:/target_dir

The above situation is very reproducible.  I have spent a substantial 
amount of time looking for this in postings, without success.  I've also 
done considerable testing with the two versions mentioned and exclude 
lists, again without success.  Is this new behavior a bug that has crept 
in, or was the behavior changed intentionally?  If it is a bug, can I 
get it added to the list to get fixed for an uncoming version?

Thanks,

LJ McDonald
-------------- next part --------------
HTML attachment scrubbed and removed

On Wed, May 18, 2005 at 04:30:58PM -0400, Lloyd J. McDonald
wrote:
>    rsync: delete_file: rmdir "dir/pdf" failed: File exists (17)
On my OS, rmdir() returns ENOTEMPTY in this case, so my testing didn't
reveal that one of two places in the improved delete code failed to
check for an EEXIST errno.  Attached is the fix.  Feel free to try it
out on 2.5.6pre1, if you like (2.5.6 is a bug-fix release, so pre1 is
a very safe pre-release).

Thanks for the report (and the excellent explanation)!

..wayne..
-------------- next part --------------
--- generator.c	13 May 2005 23:00:20 -0000	1.210
+++ generator.c	18 May 2005 23:51:03 -0000
@@ -186,7 +186,7 @@ static int delete_item(char *fname, int 
 	if (do_rmdir(fname) == 0) {
 		if (!(flags & DEL_TERSE))
 			log_delete(fname, mode);
-	} else if (errno != ENOTEMPTY && errno != ENOENT) {
+	} else if (errno != ENOTEMPTY && errno != EEXIST && errno !=
ENOENT) {
 		rsyserr(FERROR, errno, "delete_file: rmdir %s failed",
 			full_fname(fname));
 		return -1;