Bug 10522 - --detect-renamed patch is causing deletions as if a 'delete flag' was supplied, when none have been
--detect-renamed patch is causing deletions as if a 'delete flag' was supplie...
Status: RESOLVED FIXED
Product: rsync
Classification: Unclassified
Component: core
3.1.1
x86 All
: P5 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-03-28 18:41 UTC by John Pierman
Modified: 2014-04-13 18:02 UTC (History)
1 user (show)

See Also:


Attachments
revised patch detect-renamed.diff (30.16 KB, patch)
2014-04-10 02:50 UTC, J.R.
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Pierman 2014-03-28 18:41:40 UTC
Scenario:

Files are being deleted, even though no 'delete' flags are given.

Patch rsync 3.1.1pre1 with detect-renamed patch
configure
make

mkdir /tmp/test1
mkdir /tmp/test2
touch /tmp/test1/a
touch /tmp/test1/b
touch /tmp/test1/c
touch /tmp/test2/a
touch /tmp/test2/x
touch /tmp/test2/y
touch /tmp/test2/z

rsync -rvzhtSin /tmp/test1/ /tmp/test2/

"building file list ... done
*deleting   z
*deleting   y
*deleting   x
.d..t...... ./
>f..t...... a
>f+++++++++ b
>f+++++++++ c
Comment 1 John Pierman 2014-03-28 19:10:39 UTC
I'm sorry typo'd the rsync command, left out the --detect-renamed flag.
Should be 
rsync -rvzhtSin --detect-renamed /tmp/test1/ /tmp/test2/

(In reply to comment #0)
> Scenario:
> 
> Files are being deleted, even though no 'delete' flags are given.
> 
> Patch rsync 3.1.1pre1 with detect-renamed patch
> configure
> make
> 
> mkdir /tmp/test1
> mkdir /tmp/test2
> touch /tmp/test1/a
> touch /tmp/test1/b
> touch /tmp/test1/c
> touch /tmp/test2/a
> touch /tmp/test2/x
> touch /tmp/test2/y
> touch /tmp/test2/z
> 
> rsync -rvzhtSin /tmp/test1/ /tmp/test2/
> 
> "building file list ... done
> *deleting   z
> *deleting   y
> *deleting   x
> .d..t...... ./
> >f..t...... a
> >f+++++++++ b
> >f+++++++++ c
Comment 2 J.R. 2014-04-10 02:49:02 UTC
I can confirm this problem.

I suggest increasing the Severity of this bug to "Critical" because it causes data to be lost without the user requesting this.

The problem is that a small section of code was lost from detect-renamed.diff between 3.0.9 and 3.1.0:

--- delete.c.orig       2013-01-19 14:05:53.000000000 -0500
+++ delete.c    2014-04-09 22:35:59.000000000 -0400
@@ -153,6 +161,9 @@
                /* OK: try to delete the directory. */
        }

+       if (flags & DEL_NO_DELETIONS)
+               return DR_SUCCESS;
+
        if (!(flags & DEL_MAKE_ROOM) && max_delete >= 0 && stats.deleted_files >= max_delete) {
                skipped_deletes++;
                return DR_AT_LIMIT;

Putting that back fixes this problem.

I will attach a complete detect-renamed.diff that includes this correction.
Comment 3 J.R. 2014-04-10 02:50:13 UTC
Created attachment 9840 [details]
revised patch  detect-renamed.diff
Comment 4 Wayne Davison 2014-04-13 18:02:08 UTC
Thanks for the detection work.  When the patch was revised for 3.1.0 that check was apparently left in the generator.c file instead of migrating to delete.c.  I added in the check in the right place in delete.c and also removed the unmigrated check that was being added to generator.c.  This fix will be in the patches for 3.1.1.