Skip to main content
8 events
when toggle format what by license comment
Feb 27, 2021 at 13:01 comment added Chris Davies Yes, that's right. It's fundamentally about copying from source to destination, and the link-dest is purely to help speed things on their way
Feb 27, 2021 at 11:00 comment added mike rodent Thanks, working now. So the conclusion seems to be that the reporting of deletions (and additions and modifications, presumably) is relative to the destination location, not to the link-dest location. This is probably clear from the man docs ...
Feb 27, 2021 at 9:11 vote accept mike rodent
Feb 26, 2021 at 20:58 history edited Chris Davies CC BY-SA 4.0
Missed *delete vs .d
Feb 26, 2021 at 20:58 comment added Chris Davies I'm so sorry; I missed a final update to my grep when transferring from my test rig to here. Answer modified for you
Feb 26, 2021 at 19:50 comment added mike rodent Hmmm... ! Sorry to say so, but when I modify or add a file in the src location (i.e. somewhere in the directory tree), this results in a non-dry run, work to be done. But if I delete a file in the src somewhere in the tree, output is indeed a blank string! Can you possibly see whether you have different results in your system? I'm really puzzled whether this is just my system or whether rsync seemingly fails to identify deletions as (it would appear from the docs) it is intended to.
Feb 26, 2021 at 12:08 comment added mike rodent Thanks. In Linux I've used Timeshift, indeed. Actually it's not exactly like you describe, in the sense that although I compare with the previous snapshot of the particular time category (10-minutes, hour, day, week, month, etc.) for the purpose of identifying differences, I actually use the most recent snapshot in any time category for the non-dry rsync op ... since it seems to me that using the most recent snapshot will result in the most hard links and the fewest file copy operations. Will do some experiments with your solution later.
Feb 26, 2021 at 11:28 history answered Chris Davies CC BY-SA 4.0