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!
> 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!
> 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.
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.