Simple questions first...
Your KB search was probably confused by inclusion of the ! and the % characters (the last one at least is used in HTML as an escape character for hex, e.g. %20 for 'space'). There is no KB article on that function, given that there is contextual Help (press F1) on the settings page where it appears (Copy/Delete settings page). Help > Search > 'warning' (without the quotes) > 3rd hit also gets you there.
If a profile in a group Aborts, that Abort will cascade to any profiles in that group still waiting to run (for safety reasons)
We can't tell you for sure why it proposed to delete all the files (we'd need debug info to find out, although it would probably only tell us 'why the decision was taken', not 'how that state occurred'), but a common reason is that due to hardware and/or network issues, one side (usually the Source) is reported to contain 'no files*', and your rules say to replicate those apparent absences to the Destination. The setting we are referring to is designed to help trap that by choosing a level of 'expected' deletions (you can change the value from the default '100%') beyond which it suggests 'probable error condition, so Abort...'
* note that this could be something as simple as a drive letter having changed spontaneously (Windows sometimes does that...), and either the device it points to now is empty, or your Source string contains a path that doesn't exist on that device, so SB obligingly auto-creates it (c/o Copy/Delete settings page, bottom option), and of course that new path\directory is empty....
Your KB search was probably confused by inclusion of the ! and the % characters (the last one at least is used in HTML as an escape character for hex, e.g. %20 for 'space'). There is no KB article on that function, given that there is contextual Help (press F1) on the settings page where it appears (Copy/Delete settings page). Help > Search > 'warning' (without the quotes) > 3rd hit also gets you there.
If a profile in a group Aborts, that Abort will cascade to any profiles in that group still waiting to run (for safety reasons)
We can't tell you for sure why it proposed to delete all the files (we'd need debug info to find out, although it would probably only tell us 'why the decision was taken', not 'how that state occurred'), but a common reason is that due to hardware and/or network issues, one side (usually the Source) is reported to contain 'no files*', and your rules say to replicate those apparent absences to the Destination. The setting we are referring to is designed to help trap that by choosing a level of 'expected' deletions (you can change the value from the default '100%') beyond which it suggests 'probable error condition, so Abort...'
* note that this could be something as simple as a drive letter having changed spontaneously (Windows sometimes does that...), and either the device it points to now is empty, or your Source string contains a path that doesn't exist on that device, so SB obligingly auto-creates it (c/o Copy/Delete settings page, bottom option), and of course that new path\directory is empty....