Regularly larger prune runs crash for me. Then I have to manually go to the storage and delete the affacted revisions, because revisions that miss chunks can’t be pruned.
From a user perspective this does not make sense: I want to prune (=delete) a revision. Why can’t the software just delete it? If there’s something missing, I don’t care… I want it gone anyways.
So it would be fantastic if there were a -persist flag for the prune command, that doesn’t care about missing chunks, just mark everything as fossil that it can, and then remove the revision file.
1 Like
I don’t think -persist is the solution here. Instead, prune should delete (or fossilise* - i.e. rename to .fsl) the snapshot file before deleting chunks.
The issue with having a -persist flag, is that users will think to slap it on every prune they do and then you end up in a situation where they don’t care when there’s missing files coz ‘Duplicacy will take care of it’, and so never be truly aware of the real health of the storage. Duplicacy simply shouldn’t leave the storage in this state in the first place.
*Fossilise would be preferable, as then Duplicacy would have a ready list of chunks to delete on the next run - if the previous run was aborted for any reason - much better than having to use -exhaustive to clean up too.
1 Like
Agreed, if would be even better if duplicacy would never leave the storage in an inconsistent state. But before this is never implemented, I prefer a simple solution that’s working today.
Maybe as a first simple solution, duplicacy could delete snapshot files first before deleting chunks? This sounds like an easy fix.
And then whenever maintainers get around to fossilize snapshots that would be very nice then.
2 Likes