https://bugzilla.samba.org/show_bug.cgi?id=5263
------- Comment #2 from [EMAIL PROTECTED] 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. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
