rsync - Feb 2008 - DO NOT REPLY [Bug 5263] New: failure to report deleted files with link-dest

https://bugzilla.samba.org/show_bug.cgi?id=5263

           Summary: failure to report deleted files with link-dest
           Product: rsync
           Version: 3.0.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P3
         Component: core
        AssignedTo: wayned@samba.org
        ReportedBy: 14709c93@mailinator.com
         QAContact: rsync-qa@samba.org


failure to report deleted files with link-dest

# seed the source dir with some small hier
rsync -Haxvi --delete --link-dest=/tmp/0/ /usr/share/me/ /tmp/0/
<outputs copied files, correct>

# now use it as the source for the first daily snapshot
rsync -Haxvi --delete --link-dest=/tmp/0/ /tmp/0/ /tmp/1/
<no output, is correct>

# now use it as the source for the next daily snapshot
rsync -Haxvi --delete --link-dest=/tmp/1/ /tmp/0/ /tmp/2/
<no output, is correct>

# now nuke something from the source and rerun to see if it's picked up
rm 0/acm.me
rsync -Haxvi --delete --link-dest=/tmp/1/ /tmp/0/ /tmp/2/
*deleting acm.me
<this output, is correct>

# now nuke something else from the source and make the next daily snapshot
rm 0/chars.me
rsync -Haxvi --delete --link-dest=/tmp/2/ /tmp/0/ /tmp/3/
<no output, INCORRECT>

It should say: '*deleting chars.me'

It is not reporting deletions, only changes and adds. Thus one has
no idea whether nuking old snapshots is an ok thing to do because
one cannot review a proper list of changes. And running yesterdays
arguments over again the next day just to get a good log is not a
desireable practice. Marked as major because one can and will lose
files and not know it.

help :) thanks!


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=5263





------- Comment #1 from paul@debian.org  2008-02-17 07:15 CST
-------
> It should say: '*deleting chars.me'
Why? It's *not* deleting anything; it just links those files that still
exist
in /tmp/0/ via /tmp/2/ into /tmp/3/, it's not unlinking anything!


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=5263





------- Comment #2 from 14709c93@mailinator.com  2008-02-17 14:12 CST
-------
> it's not unlinking anything
Fully agreed, no unlink(2) occurs ;-]
>> It should say: '*deleting chars.me'
> Why?
Because that file existed in the prior snapshot and will not exist
in the current snapshot. Just as using rsync without link-dest would
report. Said slightly differently, why should/does rsync bother
reporting all _but_ said 'deletions' with link-dest. Rsync uses 
link-dest to allow slick incremental deltas and storage efficiency.
It seems inconsistent to lose the reporting of said 'deletions'     
with that.

In general, rsync seems to take pride in telling the user exactly
what has changed between runs and why. That is a good thing. And
it has been getting better at doing so which is also good.

I'd like to be able to know what has changed. Without having to
rerun as described and eating the time race in between or running
2 against 3 later with no race. Both as a log pass with -n of course.

Possible solutions:

There is already one compare pass from 0 into 3 via 2. It is out   
of context to examine for said 'deletions' in that direction. So
we are left with...

If the index to 0 is available, 2 could be checked against 0.
.or.
2 could be checked against 3.

With both checking only for existance as sufficient and possibly 
faster/lighter because the rest of stat isn't needed.

Whichever method prevails, if not exist, print deleted. If it is
expensive to do so by default, it could be an option for pedants.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=5263


wayned@samba.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Comment #3 from wayned@samba.org  2008-03-15 03:19 CST -------
Rsync does limit its output of changed files when a --link-dest/etc. option is
in effect, making it appear like the copy is updating the alt-dest dir while
really creating a new directory of files.  Delete does not play along with this
extended view of how the copy is working, and indeed, does absolutely nothing
when using --link-dest into an empty directory.

It might be nice to enable such a feature, as that would round out the
augmented-copy effect of the option.  One way to achieve this without much work
at all would be for rsync to do a dry-run delete pass into the last alt-dest
directory that the user provided (either before, during, or after the copying,
as appropriate).  That would generate the output you expect while leaving the
files alone in the other directory.

Perhaps if rsync notices that the destination directory was created by rsync or
is empty, an alt-dest option was provided, and one of the --delete options was
specified (which would normally be useless), then it could output this extra
delete info.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.