Comment 4 for bug 1770528

Hi,

I was one of the main developers of Sbackup.
I have devoted myself to other projects for quite some time now (leaving sbackup to others).
Developers interested in this project come and go depending on their free time.
This explains the time it took for you to have and answer to your questions.

I want to praise you for the effort you put on analyzing the issue.

In your example, the way you expected Sbackup to work is to do the action described bellow:

2018-04-25_22.00.11.927348.mcs-Ubuntu.ful/ <------ CUTOFF
2018-04-26_22.00.08.250440.mcs-Ubuntu.inc/ <------ CUTOFF
2018-04-27_22.00.07.487993.mcs-Ubuntu.inc/ <------ CUTOFF
2018-04-28_22.00.08.383888.mcs-Ubuntu.inc/ <------ CUTOFF
2018-04-29_22.00.06.820683.mcs-Ubuntu.inc/ <------ CUTOFF
2018-04-30_22.00.08.240341.mcs-Ubuntu.inc/
2018-05-01_22.00.08.232810.mcs-Ubuntu.inc/
2018-05-02_22.00.07.980758.mcs-Ubuntu.ful/
2018-05-03_22.00.07.042217.mcs-Ubuntu.inc/
2018-05-04_22.00.08.945832.mcs-Ubuntu.inc/
2018-05-05_22.00.07.219102.mcs-Ubuntu.inc/
2018-05-06_22.00.08.145880.mcs-Ubuntu.inc/
2018-05-07_22.00.08.746766.mcs-Ubuntu.inc/
2018-05-08_22.00.08.245251.mcs-Ubuntu.inc/
2018-05-09_22.00.07.699726.mcs-Ubuntu.ful/

However, doing this would leave 2 *orphans backups*

2018-04-30_22.00.08.240341.mcs-Ubuntu.inc/
2018-05-01_22.00.08.232810.mcs-Ubuntu.inc/

What I call orphan backup here is a backup you would not be able to use (because you would not be able to revert a folder from it. Every Incremental backup has to have a parent (Full backup). So even with the Simple cutoff fonctionnality, we don't want you to lose the 2 incremental backups that would have been left on the disk. So Sbackup will only remove all the backups that are before the parent of the 2 inc backup.
This explain the situation you got.

I agree however that is not described in the documentation. I would welcome any suggestion on the way to describe it in a user friendly way.