Bug 5263 - add a way to report deletions when copying into an empty dir using a --*-dest option
Summary: add a way to report deletions when copying into an empty dir using a --*-dest...
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.0.0
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2008-02-15 16:53 UTC by hoffa
Modified: 2022-11-10 12:25 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description hoffa 2008-02-15 16:53:17 UTC
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!
Comment 1 Paul Slootman 2008-02-17 07:15:04 UTC
> 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!
Comment 2 hoffa 2008-02-17 14:12:32 UTC
> 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.
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.
Comment 3 Wayne Davison 2008-03-15 03:19:03 UTC
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.