Prune should first delete the snapshot and afterwards delete the chunks

implemented
prune

#1

Continuing the discussion from Deleted chunk during backup:

Is there a difference if the deletion of a snapshot happens in the deletion phase or in the fossilization?


#3

On second thoughts, this might be a more complicated procedure. It would have to make sure none of the chunks to be deleted have subsequently made their way back into new revisions. As such, a prune might have to run in two phases? Yep, much more complicated.


If you're running prune and backup in parallel, please upgrade to 2.1.1
split this topic #4

5 posts were split to a new topic: SFTP check command is very slow

I cleaned the thread, as this is a feature request, and your posts are unrelated.
C’mon guys, don’t steal the thread like that :wink:.


#6

I now believe that the order of deleting snapshots and chunks doesn’t matter. When a prune command performing the fossil collection step is aborted for any reason before deleting the snapshots, the chunks to be deleted are simply marked as fossils and still exist in the storage. It is only in the fossil deletion step that these fossils will be permanently removed from the storage. So a simple fix is to record the snapshots to be deleted in the fossil collection file. When the prune command is run again to performance the fossil deletion step, it will then check if these supposedly deleted snapshots still exist. If any of these deleted snapshots can be found, then this fossil collection should not be processed and should be nuked instead.


#7

I think this feature is now implemented in

Right?


closed #8

Since the feature is now implemented i have closed this topic.
If there are any bugs a new topic should be created.