DO NOT REPLY [Bug 5263] failure to report deleted files with link-dest

samba-bugs at samba.org samba-bugs at samba.org
Sun Feb 17 20:12:33 GMT 2008


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





------- Comment #2 from 14709c93 at 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.


More information about the rsync mailing list