I was trying to see how prune works for b2. This was the scenario:
- create a few files (set-1) in the src repo.
- back these up as rev-1
- delete set-1 and create new set of files - set-2 at src.
- back these up as rev-2
- delete set-2 and re-create set-1
- back these up as rev-3
- move snapshot file 3 somewhere else so duplicacy cannot find it (so does not know about rev-3)
prune -r 1which fossilises all chunks due to rev-1 and snapshot rev-1 is deleted. Fossil collection file reflects these
- move snapshot file for rev-3 back to
snapshots/iddir at the storage
- I ran
prune(like in step-12 below) here thinking it will resurrect everything as now it knows about a new rev-3 which references everything that rev-1 did - but nothing happened and exited saying that deletion criteria was not met. So basically it did nothing.
- do one more backup do have backup at rev-4
prunewithout any revisions given so it deals only with the local fossil-collection file that was previously created.
With local storage, duplicacy has the advantage to just rename the chunks with
.fsl extension and resurrection means to just remove that
.fsl extension. With b2, there’s no rename so probably does something with the hide-marker which would create one more version of that file (a b2 revision/version, not to be confused with duplicacy revisions).
Till here, I (hopefully) understand.
Now the difference is in step 11. Before this step (backing up for rev-3), the fossilisation in the file-path storage is shown as a
.fsl file and subsequent backup (rev-4) resurrects it. I was surprised a bit here as i thought (or i read it somewhere) it would create new files as backup doesn’t look at fossilised files unlike
prune, but it’s a good thing ofc. if it does. The prune then has nothing to do so just exits saying chunks already exist.
For b2, the first prune did fossilisation by probably putting a hidden-marker. So i can see upstream that those chunk dirs are marked with
* and in there it says there are 2 versions of the file. Step 11 does not resurrect them and in-fact I now have 3 versions (copies ?) of those files as shown online via their website. Only after i run step-12 do those reduce to containing just 1 file.
Why couldn’t the backup simply delete the hidden marker there which would behave similar to the file-path storage (resurrection) ? Till i run a subsequent prune it seems i might have 3 copies of a lot of files.
Also why did step-10 do nothing ? I’m suspecting this is something to do with timestamps and sorts ?